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.

Imho if I dropped a table I would not like another session to still access
it,
so we should imho rather fix pg_dump.

Andreas

-----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."

* 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."