Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
От | Teodor Sigaev |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Дата | |
Msg-id | 731645f2-37a9-635d-7c58-927335a50778@sigaev.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
|
Список | 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/
В списке pgsql-hackers по дате отправления: