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
before we want to drop it. (This is the situation where Dmitry and I found
this bug.) We would do
1. exec statement "SELECT last_value from sA" to get the last value of this
sequence.
2. increment this last value
3. drop the sequence sA.
We have seen that this fixed the problem.
I am not sure we can absolutely guarantee that the last value we get this
way would be the same as calling "nextval", since another request might
change the sequence we want to drop (depending on transaction mode?).
However we can live with it since dropping sequence does not happen often at
all.
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 NO problem in this situation. Also the analysis
from Tom Lane seems confirming this. But I am still not sure on this.
Thanks,
Heng Sun