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

Teodor Sigaev <teodor@sigaev.ru>

From: Teodor Sigaev <teodor@sigaev.ru>
To: Heikki Linnakangas <hlinnaka@iki.fi>, 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-09T11:35:05Z
Lists: pgsql-hackers
> 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.
Thank you for reserching!

Proof of concept:
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 43b2fce2c5..b8291f96e2 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -10745,6 +10745,7 @@ ATExecSetRelOptions(Relation rel, List *defList, 
AlterTableType operation,
         case RELKIND_INDEX:
         case RELKIND_PARTITIONED_INDEX:
             (void) index_reloptions(rel->rd_amroutine->amoptions, newOptions, 
true);
+           TransferPredicateLocksToHeapRelation(rel);
             break;
         default:
             ereport(ERROR,

it fixes pointed bug, but will gives false positives. Right place for that in 
ginoptions function, but ginoptions doesn't has an access to relation structure 
and I don't see a reason why it should.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/


Commits

  1. Re-think predicate locking on GIN indexes.

  2. Predicate locking in GIN index