RE: bug with dropping tables and transactions.
От | Hiroshi Inoue |
---|---|
Тема | RE: bug with dropping tables and transactions. |
Дата | |
Msg-id | 000c01c01c8d$c4accf80$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | bug with dropping tables and transactions. (Alfred Perlstein <bright@wintelcom.net>) |
Ответы |
Re: bug with dropping tables and transactions.
|
Список | pgsql-hackers |
> -----Original Message----- > From: Alfred Perlstein > > There seems to a race condition somewhere where that if you're > running let's say pg_dumpall and happen to drop a table mid-dump > pg_dumpall will die because it looses the table. > > Would it make sense to use a transaction system so that when a table > is renamed/dropped it doesn't actually go away until all transactions > that started before the drop take place? > > one could do probably implement this using refcounts and translating > dropped tables into temporary mangled names. > Your proposal seems to be an extension of how to commit/rollback DDL (drop/alter/rename etc ..) commands properly. There has been a long discussion about it but unfortunately we have no consensus for it AFAIK. There may be another way. pg_dump(all) may be able to acquire a e.g share lock for pg_class to prevent drop/rename/.. operations of other backends. Of cource DDL(drop/rename/..) commands should acquire a row exclusive lock on pg_class. Regards. Hiroshi Inoue
В списке pgsql-hackers по дате отправления: