From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE lock strength reduction patch is unsafe |
Date: | 2011-06-17 08:40:12 |
Message-ID: | BANLkTim+529wVosOMoaP=v_-MD0Rhk+GfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 17, 2011 at 9:32 AM, simon <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-06-17 08:46:32 | Re: Boolean operators without commutators vs. ALL/ANY |
Previous Message | Simon Riggs | 2011-06-17 08:32:46 | Re: ALTER TABLE lock strength reduction patch is unsafe |