From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Shubham Barai <shubhambaraiss(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
Subject: | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Date: | 2018-03-13 12:26:15 |
Message-ID: | A762EADE-8321-4F6D-8EC5-01DDC73A08AF@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
> 13 марта 2018 г., в 17:02, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-03-13 12:28:03 | Re: ALTER TABLE ADD COLUMN fast default |
Previous Message | Alvaro Herrera | 2018-03-13 12:25:10 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-03-13 17:01:05 | Re: Bogus reports from coverage.postgresql.org |
Previous Message | Alvaro Herrera | 2018-03-13 12:25:10 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |