Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date
Msg-id 190cd793-cb1c-e40d-fb78-605d565f2b3e@sigaev.ru
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Teodor Sigaev <teodor@sigaev.ru>)
List 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 by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.
Next
From: Geoff Winkless
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS