From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jesper Engman <jesper(at)engman(dot)net> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #6167: pg_dump fails on table lock |
Date: | 2011-08-18 19:59:57 |
Message-ID: | 3308.1313697597@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jesper Engman <jesper(at)engman(dot)net> writes:
> 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
> vulnerability?
Certainly. pg_dump has to read pg_class to get the names of the tables,
and then try to lock each one. If you drop a table during that window,
the lock command will fail.
The window is actually a bit longer than necessary in existing releases,
because pg_dump was doing some other stuff before it got around to
acquiring the locks. I fixed that recently
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=68d977a73
but that patch hasn't made it to any released versions yet. In any case
there's still a nonzero window.
> Excluding tables from the dump is not an option - that will be an
> incomplete backup.
Um ... if you know it's a transient table, why do you care about backing
it up?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Mamin | 2011-08-19 11:53:06 | BUG #6168: db_link may generate additional unformatted log entries in stderr |
Previous Message | Jesper Engman | 2011-08-18 19:04:30 | Re: BUG #6167: pg_dump fails on table lock |