Re: Logical decoding & exported base snapshot - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Logical decoding & exported base snapshot
Date
Msg-id 17860.1355356353@sss.pgh.pa.us
Whole thread Raw
In response to Re: Logical decoding & exported base snapshot  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Logical decoding & exported base snapshot
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2012-12-12 12:13:44 +0100, Andres Freund wrote:
>> This morning I wondered whether we couldn't protect against that by
>> acquiring share locks on the catalog rows pg_dump reads, that would
>> result in "could not serialize access due to concurrent update" type of
>> errors which would be easy enough discernible/translateable.
>> While pretty damn ugly that should take care of most of those issues,
>> shouldn't it?

How would it fix anything?  The problem is with DDL that's committed and
gone before pg_dump ever gets to the table's pg_class row.  Once it
does, and takes AccessShareLock on the relation, it's safe.  Adding a
SELECT FOR SHARE step just adds more time before we can get that lock.

Also, locking the pg_class row doesn't provide protection against DDL
that doesn't modify the relation's pg_class row, of which there is
plenty.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Logical decoding & exported base snapshot
Next
From: Andres Freund
Date:
Subject: Re: Logical decoding & exported base snapshot