Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date
Msg-id 20160609025906.GD836559@tornado.leadboat.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
On Fri, Jun 03, 2016 at 04:29:40PM -0500, Kevin Grittner wrote:
> On Fri, May 27, 2016 at 10:35 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> > On Tue, May 24, 2016 at 4:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> >> [ANALYZE of index with expression may fail to update statistics
> >> if ANALYZE runs longer than old_snapshot_threshold]
>
> >> If we can get away with it, it would be a rather large win to only set
> >> a snapshot when the table has an expression index.  For purposes of
> >> "snapshot too old", though, it will be important that a function in an
> >> index which tries to read data from some other table which has been
> >> pruned cancels itself when necessary.
> >
> > I will make this my top priority after resolving the question of whether
> > there is an issue with CREATE INDEX.  I expect to have a resolution,
> > probably involving some patch, by 3 June.
>
> Due to 9.5 bug-fixing and the index issue taking a bit longer than
> I expected, this is now looking like a 7 June resolution.

This PostgreSQL 9.6 open item is past due for your status update.  Kindly send
a status update within 24 hours, and include a date for your subsequent status
update.  Refer to the policy on open item ownership:
http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Declarative partitioning
Next
From: Noah Misch
Date:
Subject: Re: Perf Benchmarking and regression.