"Heng Sun" <[EMAIL PROTECTED]> writes:
> But my question is: will this completely get around the problem of server
> corrupt? In particular, if in a transaction, the "nextval" is called on a
> sequence different from the sequence we are trying to drop, would there be a
> problem? My tests showed N
>From the explanation of Tom Lane, it seems we could get around the problem
in this way: avoid using "nextval" etc. on the sequence to be dropped in the
same transaction. The details can be like this. Support we want to drop a
sequence sA and would like to get the next available sA sequence value
[EMAIL PROTECTED] 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(),
[EMAIL PROTECTED] writes:
> The follow short sequence of SQL requests leads to server corrupt:
Looks like a bug to me too. I can still replicate the "NOTICE:
LockRelease: no such lock" in current sources, but it seems that
someone's already fixed the core dump; CVS tip does not crash.
Will look
