| From: | Joe Abbate <jma(at)freedomcircle(dot)com> | 
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: pg_dump issues | 
| Date: | 2011-10-02 21:15:53 | 
| Message-ID: | 4E88D489.7060102@freedomcircle.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hi Andrew,
On 10/01/2011 09:46 PM, Andrew Dunstan wrote:
> 
> 
> On 10/01/2011 05:48 PM, Joe Abbate wrote:
>> On 10/01/2011 05:08 PM, Andrew Dunstan wrote:
>>> There is also this gem of behaviour, which is where I started:
>>>
>>>     p1                p2
>>>     begin;
>>>     drop view foo;
>>>                        pg_dump
>>>     commit;
>>>                        boom.
>>>
>>> with this error:
>>>
>>>     2011-10-01 16:38:20 EDT [27084] 30063 ERROR:  could not open
>>>     relation with OID 133640
>>>     2011-10-01 16:38:20 EDT [27084] 30064 STATEMENT:  SELECT
>>>     pg_catalog.pg_get_viewdef('133640'::pg_catalog.oid) AS viewdef
>>>
>>> Of course, this isn't caused by having a large catalog, but it's
>>> terrible nevertheless. I'm not sure what to do about it.
>> Couldn't you run pg_dump with --lock-wait-timeout?
>>
> 
> How would that help? This isn't a lock failure.
I misinterpreted the error.  I have confirmed the behavior you see.  I'm
somewhat surprised there appears to be no ability to lock a database
exclusively for something like pg_dump/pg_restore, so you're not
surprised by concurrent activity against the catalogs.  I'm guessing the
assumption is that MVCC will take care of that?
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-10-02 21:25:19 | Re: build times | 
| Previous Message | Tom Lane | 2011-10-02 21:05:38 | Should we get rid of custom_variable_classes altogether? |