Re: pg_dump issues

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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?