On Mon, Jul 18, 2016 at 9:10 PM, Noah Misch <n...@leadboat.com> wrote: > 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
As far as I can see, to do this the way that Andres and Amit suggest involves tying in to indexam.c and other code in incredibly ugly ways. I think it is entirely the wrong way to go, as I can't find a way to make it look remotely sane. The question is whether I should do it the way that I think is sane, or whether someone else wants to show me what I'm missing by producing at least a rough patch along these lines. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
