Re: Bug #671: server corrupt

pgsql-bugs@postgresql.org writes:
> Is there a patch that fixs this problem?
> If there is no patch, what is the root of the problem? Is there a kit of rules to avoid this situation?

After more detailed investigation, I find both the notice and the
subsequent crash have the same cause: after nextval(), sequence.c is
holding a reference to an open relation cache entry for the sequence,
which it intends to close at end of transaction.  When you drop the
sequence later in the same transaction, the cache entry goes away,
leaving sequence.c with a dangling pointer.  Its attempt to close the
cache entry at commit not only causes the NOTICE complaint from the lock
manager, but also modifies memory that may by now have been assigned to
something else.  The crash in your example was due to another cache
entry having been corrupted in this way.

A proper fix will require revising the way sequence.c holds its state;
that strikes me as too large a change to risk back-patching into 7.2.*
--- especially for a bug that has gone unnoticed for many years.  AFAIK
sequence.c has always been implemented like this, and thus has always
had this problem.

I will fix it for 7.3, but in the meantime I suggest not dropping a
sequence that you've nextval'd, currval'd, or setval'd earlier in the
same transaction.  As a stopgap defense I will probably back-patch
something to make it error out if you try.

            regards, tom lane