From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Potential bug in pg_dump ... |
Date: | 2001-12-17 22:06:51 |
Message-ID: | 7593.1008626811@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> At 14:10 17/12/01 -0500, Marc G. Fournier wrote:
>> Got a report the other day of a "problem" with pg_dump where, if in the
>> middle of a dump, someone happens to drop a table, it errors out with:
> pg_dump runs in a single TX, which should mean that metadata changes in
> another process won't affect it. Have I misunderstood the way PG handles
> metadata changes?
In the case Marc is describing, pg_dump hasn't yet tried to touch the
table that someone else is dropping, so it has no lock on the table,
so the drop is allowed to occur.
A possible (partial) solution is for pg_dump to obtain a read-lock on
every table in the database as soon as it sees the table mentioned in
pg_class, rather than waiting till it's ready to read the contents of
the table. However this cure might be worse than the disease,
particularly for people running "pg_dump -t table".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-18 00:05:13 | Re: [HACKERS] Problem compiling postgres sql --with-tcl |
Previous Message | Peter Eisentraut | 2001-12-17 22:03:05 | Re: Explicit config patch 7.2B4, not "-C" ?? |