From: | "'Alfred Perlstein'" <bright(at)wintelcom(dot)net> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: bug with dropping tables and transactions. |
Date: | 2000-09-12 08:34:46 |
Message-ID: | 20000912013446.I12231@fw.wintelcom.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)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(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2000-09-12 10:03:43 | Re: FYI - Build problems when an RPM version is installed |
Previous Message | Alfred Perlstein | 2000-09-12 08:32:23 | Re: bug with dropping tables and transactions. |