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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
