Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
От | Teodor Sigaev |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Дата | |
Msg-id | 190cd793-cb1c-e40d-fb78-605d565f2b3e@sigaev.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) (Teodor Sigaev <teodor@sigaev.ru>) |
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: