From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Alfred Perlstein" <bright(at)wintelcom(dot)net> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: bug with dropping tables and transactions. |
Date: | 2000-09-12 07:47:58 |
Message-ID: | 000c01c01c8d$c4accf80$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----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
From | Date | Subject | |
---|---|---|---|
Next Message | Alfred Perlstein | 2000-09-12 08:32:23 | Re: bug with dropping tables and transactions. |
Previous Message | Zeugswetter Andreas SB | 2000-09-12 07:42:41 | AW: new relkind for view |