DDL is not excluded from MVCC, right? This kind of concurrency should
be handled and it's generally managed just fine. I just did a lab test
attempting to drop a table while pg_dump is running on the same db and
it simply waits to drop the table until pg_dump is done. That is the
There is some discussion about concurrency and DDL changes in:
But in that case, some specialized backend functions like
pg_get_indexdef is using committed state and that doesn't seem to
occur in this case.
I wonder if there is a small time span between when pg_dump starts and
when all locks have been acquired that may be the problem (if a table
is dropped during that time span). Is there such a small time of
The database in question does not have a ton of tables like this -
about 10 tables and the tables exists for about 5 min. But this runs
on many databases (more than a thousand). So, if there is a window of
vulnerability (if only small) - chances are we're hitting it.
Excluding tables from the dump is not an option - that will be an
On Thu, Aug 18, 2011 at 4:03 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, Aug 18, 2011 at 2:05 AM, Jesper Engman <jesper(at)engman(dot)net> wrote:
>> The following bug has been logged online:
>> Bug reference: 6167
>> Logged by: Jesper Engman
>> Email address: jesper(at)engman(dot)net
>> PostgreSQL version: 8.3.10
>> Operating system: Linux
>> Description: pg_dump fails on table lock
>> I have tables that exists for short time periods, sometimes for as short as
>> 5 min. pg_dump is starting to fail due to a problem to lock these tables:
>> pg_dump: SQL command failed
>> pg_dump: Error message from server: ERROR: relation
>> "vehicle_change_partitions.vehicle_change_export_p4368494" does not exist
>> pg_dump: The command was: LOCK TABLE
>> vehicle_change_partitions.vehicle_change_export_p4368494 IN ACCESS SHARE
>> Backup failed: PGPASSWORD=xxxxx && export PGPASSWORD && export PGOPTIONS="-c
>> statement_timeout=0 -c maintenance_work_mem=2147483647" && /usr/bin/pg_dump
>> -h xxx.xxx.xxx.xxx -U postgres --ignore-version -Fc -Z 6 xxxxxxxx >
>> Account: xxxxxxxx Backup failed
>> How is this possible - pg_dump is a serializable transaction? It doesn't
>> seem to be tripped up by some other backend function since this actually
>> fails on the lock.
> Well, its not a bug.
> You've asked to dump a table and then dropped the table concurrently
> with the attempt to dump the table.
> Exclude the tables you don't wish to have dumped using command line options.
> I don't think we will put in an option to silently exclude missing
> tables, not least because it would be technically difficult.
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2011-08-18 19:59:57|
|Subject: Re: BUG #6167: pg_dump fails on table lock |
|Previous:||From: Simon Riggs||Date: 2011-08-18 11:03:04|
|Subject: Re: BUG #6167: pg_dump fails on table lock|