Re: bug with dropping tables and transactions.
От | 'Alfred Perlstein' |
---|---|
Тема | Re: bug with dropping tables and transactions. |
Дата | |
Msg-id | 20000912013446.I12231@fw.wintelcom.net обсуждение исходный текст |
Ответ на | AW: bug with dropping tables and transactions. (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
* Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> [000912 00:37] wrote: > > > 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. > > Imho if I dropped a table I would not like another session to still access > it, > so we should imho rather fix pg_dump. Not a session, but a transaction. I'm not adverse to an option that extends DROP to behave the way I'd like it to rather than having pg_dump fail, but I'm not happy with pg_dump locking up my database, I'm already hacking around way to much to avoid deadlocks and stalls due to vacuum, and I'd really rather not have pg_dump become my new nemisis. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
В списке pgsql-hackers по дате отправления: