Ugh, I miss your last email where you another locking protocol. Reading.
Teodor Sigaev wrote:
>> 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/
