| 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: | Whole Thread | Raw Message | 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. |