Thread: bug with dropping tables and transactions.
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.
table foo begin transaction
drop table foo foo becomes foo~1 for all transactions started before the drop
end transaction
foo~1 and mapping are
dropped.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
> -----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
* Hiroshi Inoue <Inoue@tpf.co.jp> [000912 00:45] wrote: > > -----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. No long term locks is better than a locking system, I'd prefer to be able to proceed as normal since a transaction exists 'at a point in time' there's no reason to delay a drop that happens in the future so long as there's still something for the old transaction to grab onto. Your solution may be simpler (and I thought of something like it already) but honestly it's not what I'd like to see implemented. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."