On Sat, Jul 16, 2016 at 06:48:08PM -0400, Noah Misch wrote:
> On Wed, Jul 13, 2016 at 03:57:02PM -0500, Kevin Grittner wrote:
> > On Wed, Jul 13, 2016 at 12:48 PM, Andres Freund <and...@anarazel.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.kapil...@gmail.com> 
> > >> wrote:
> > >>> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner <kgri...@gmail.com> 
> > >>> wrote:
> > >>>> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund <and...@anarazel.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.ga447...@tornado.leadboat.com

IMMEDIATE ATTENTION REQUIRED.  This PostgreSQL 9.6 open item is long past due
for your status update.  Please reacquaint yourself with the policy on open
item ownership[1] and then reply immediately.  If I do not hear from you by
2016-07-20 03:00 UTC, I will transfer this item to release management team
ownership without further notice.

[1] 
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to