Re: Potential bug in pg_dump ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Potential bug in pg_dump ...
Date
Msg-id 7593.1008626811@sss.pgh.pa.us
Whole thread Raw
In response to Re: Potential bug in pg_dump ...  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Potential bug in pg_dump ...  (Brent Verner <brent@rcfile.org>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.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


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Potential bug in pg_dump ...
Next
From: Peter Eisentraut
Date:
Subject: Re: Explicit config patch 7.2B4, not "-C" ??