Horton

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>, Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Shubham Barai <shubhambaraiss@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Andrew Borodin <amborodin86@gmail.com>, Kevin Grittner <kgrittn@gmail.com>
Date: 2018-04-09T06:23:21Z
Lists: pgsql-hackers

Attachments

On 16/03/18 00:26, Alexander Korotkov wrote:
> On Tue, Mar 13, 2018 at 3:26 PM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>> On 13/03/18 14:02, Alexander Korotkov wrote:
>>> And what happen if somebody concurrently set (fastupdate = on)?
>>> Can we miss conflicts because of that?
>>
>> No, AccessExclusiveLock will prevent this kind of problems with enabling
>> fastupdate.
> 
> True.  I didn't notice that ALTER INDEX SET locks index in so high mode.
> Thus, everything is fine from this perspective.

Nope, an AccessExclusiveLock is not good enough. Predicate locks stay 
around after the transaction has committed and regular locks have been 
released.

Attached is a test case that demonstrates a case where we miss a 
serialization failure, when fastupdate is turned on concurrently. It 
works on v10, but fails to throw a serialization error on v11.

- Heikki

Commits

  1. Re-think predicate locking on GIN indexes.

  2. Predicate locking in GIN index