Re: bug with dropping tables and transactions.

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

In response to

Browse pgsql-hackers by date

  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.