Re: bug with dropping tables and transactions. - Mailing list pgsql-hackers

From 'Alfred Perlstein'
Subject Re: bug with dropping tables and transactions.
Date
Msg-id 20000912013446.I12231@fw.wintelcom.net
Whole thread Raw
In response to AW: bug with dropping tables and transactions.  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List 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 by date:

Previous
From: Alfred Perlstein
Date:
Subject: Re: bug with dropping tables and transactions.
Next
From: "Valter Mazzola"
Date:
Subject: Re: Patch for TNS services