| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Joe Abbate <jma(at)freedomcircle(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump issues |
| Date: | 2011-10-03 15:21:02 |
| Message-ID: | 15826.1317655262@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Oct 1, 2011 at 9:46 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> How would that help? This isn't a lock failure.
> It is, rather, a failure to lock. Currently, LOCK TABLE only works on
> tables, and pg_dump only applies it to tables. If the offending
> object had been a table rather than a view, pg_dump would (I believe)
> have blocked trying to obtain an AccessShareLock against the existing
> AccessExclusiveLock.
Yeah, and it would still have failed once the lock was released.
Short of providing some sort of global DDL-blocking lock (with attendant
performance consequences) it's not clear how to create an entirely
bulletproof solution here. This isn't a new problem --- we've been
aware of pg_dump's limitations in this area for many years.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2011-10-03 15:27:09 | Re: Bug with pg_ctl -w/wait and config-only directories |
| Previous Message | Tom Lane | 2011-10-03 15:16:31 | Re: Should we get rid of custom_variable_classes altogether? |