Re: Potential bug in pg_dump ...

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

In response to

Responses

Browse pgsql-hackers by date

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