Horton

Re: ALTER TABLE lock strength reduction patch is unsafe

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-17T08:40:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add bytea_agg, parallel to string_agg.

  2. Fix ALTER TABLE ONLY .. DROP CONSTRAINT.

On Fri, Jun 17, 2011 at 9:32 AM, simon <simon@2ndquadrant.com> wrote:
> On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> 2. In response, some other backend starts to reload its relcache entry
>> for pgbench_accounts when it begins its next command.  It does an
>> indexscan with SnapshotNow on pg_class to find the updated pg_class row.
>>
>> 3. Meanwhile, some third backend commits another ALTER TABLE, updating
>> the pg_class row another time.  Since we have removed the
>> AccessExclusiveLock that all variants of ALTER TABLE used to take, this
>> commit can happen while backend #2 is in process of scanning pg_class.
>
> This part is the core of the problem:
>
> We must not be able to update the catalog entry while a relcache rebuild scan is in place.
>
> So I'm prototyping something that allows
> LockRelationDefinitionOid(targetRelId, ShareLock);

Similar to the way we lock a relation for extension, as a sub-lock of
the main relation lock.

Relcache rebuilds use a ShareLock, ALTER TABLE uses an ExclusiveLock.

I've written the patch, just need to test later today.... gotta step out now.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services