Обсуждение: 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."