> If we're going to try to retroactively make the world safe for pgpool > doing what it's doing, the only way is to start including sequences in > the set of objects that are vacuumed and included in > relfrozenxid/datfrozenxid bookkeeping. Which is a lot more overhead > than I think is justified to clean up after a bad decision. I'm not > even terribly sure that it would work, since nobody has ever looked at > what would happen if nextval executed concurrently with vacuum doing > something to a sequence. The relfrozenxid logic might have some > difficulty with sequences that have zero relfrozenxid to start with, > too.
What pgpool really wanted to do was locking sequence tables, not locking rows in sequences. I wonder why the former is not allowed. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
