On Wed, Jul 13, 2016 at 03:57:02PM -0500, Kevin Grittner wrote:
> On Wed, Jul 13, 2016 at 12:48 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote:
> >> On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >>> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> >>>> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >>>>
> >>>>> I'm a bit confused, why aren't we simply adding LSN interlock
> >>>>> checks for toast? Doesn't look that hard? Seems like a much more
> >>>>> natural course of fixing this issue?
> >>>>
> >>>> I took some time trying to see what you have in mind, and I'm
> >>>> really not "getting it".
> >>>
> >>> Isn't it possible if we initialize lsn and whenTaken in SnapshotToast
> >>> when old_snapshot_threshold > 0 and add a check for
> >>> HeapTupleSatisfiesToast in TestForOldSnapshot()?
> >>
> >> With that approach, how will we know *not* to generate an error
> >> when reading the chain of tuples for a value we are deleting. Or
> >> positioning to modify an index on toast data. Etc., etc. etc.
> >
> > I'm not following. How is that different in the toast case than in the
> > heap case?
>
> A short answer is that a normal table's heap doesn't go through
> systable_getnext_ordered(). That function is used both for cases
> where the check should not be made, like toast_delete_datum(), and
> cases where it should, like toast_fetch_datum().
>
> Since this keeps coming up, I'll produce a patch this way. I'm
> skeptical, but maybe it will look better than I think it will. I
> should be able to post that by Friday.
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