Re: pgpool versus sequences
| От | Tatsuo Ishii |
|---|---|
| Тема | Re: pgpool versus sequences |
| Дата | |
| Msg-id | 20110602.080816.460114267356667394.t-ishii@sraoss.co.jp обсуждение исходный текст |
| Ответ на | Re: pgpool versus sequences (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: pgpool versus sequences
|
| Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: