Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <kgrittn(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "pgsql-committers(at)postgresql(dot)org" <pgsql-committers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date: 2016-06-07 15:40:28
Message-ID: CA+TgmoZofYUFFTd5_jfwdzMWmzJqsg_Wr36m=cCCkbgYkPGt3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
>> Consequently, causing the index to be ignored in planning when
>> using the old index
>
> That last line should have read "using an old snapshot"
>
>> is not a nice optimization, but necessary for
>> correctness. We already have logic to do this for other cases
>> (like HOT updates), so it is a matter of tying in to that existing
>> code correctly. This won't be all that novel.
>
> Just to demonstrate that, the minimal patch to fix behavior in this
> area would be:
>
> diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
> index 31a1438..6c379da 100644
> --- a/src/backend/catalog/index.c
> +++ b/src/backend/catalog/index.c
> @@ -2268,6 +2268,9 @@ IndexBuildHeapRangeScan(Relation heapRelation,
> Assert(numblocks == InvalidBlockNumber);
> }
>
> + if (old_snapshot_threshold >= 0)
> + indexInfo->ii_BrokenHotChain = true;
> +
> reltuples = 0;
>
> /*
>
> Of course, ii_BrokenHotChain should be renamed to something like
> ii_UnsafeForOldSnapshots, and some comments need to be updated; but
> the above is the substance of it.

I don't know why we'd want to rename it like that...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-06-07 15:44:16 pgsql: Update isn extension for parallel query.
Previous Message Stephen Frost 2016-06-07 15:14:53 pgsql: Minor typos / copy-editing for snapmgr.c

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-07 15:42:27 Re: Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Previous Message Robert Haas 2016-06-07 15:32:50 Re: Parallel query and temp_file_limit