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
-
Re-think predicate locking on GIN indexes.
- 0bef1c0678d9 11.0 landed
-
Predicate locking in GIN index
- 43d1ed60fdd9 11.0 landed