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

From Andrey Borodin
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date
Msg-id A762EADE-8321-4F6D-8EC5-01DDC73A08AF@yandex-team.ru
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers

> 13 марта 2018 г., в 17:02, Alexander Korotkov <a.korotkov@postgrespro.ru> написал(а):
>
> BTW to BTW. I think we should check pending list size with GinGetPendingListCleanupSize() here
> +
> +       /*
> +        * If fast update is enabled, we acquire a predicate lock on the entire
> +        * relation as fast update postpones the insertion of tuples into index
> +        * structure due to which we can't detect rw conflicts.
> +        */
> +       if (GinGetUseFastUpdate(ginstate->index))
> +               PredicateLockRelation(ginstate->index, snapshot);
>
> Because we can alter alter index set (fastupdate = off), but there still will be pending list.
>
> And what happen if somebody concurrently set (fastupdate = on)?
> Can we miss conflicts because of that?
No, AccessExclusiveLock will prevent this kind of problems with enabling fastupdate.

Best regards, Andrey Borodin.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Next
From: Andrew Dunstan
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default