Re: BUG #14150: Attempted to delete invisible tuple

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Oskari Saarenmaa <os(at)aiven(dot)io>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Tripp <peter(at)chartio(dot)com>, Virendra Negi <virendra(at)idyllic-software(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14150: Attempted to delete invisible tuple
Date: 2016-07-07 22:02:43
Message-ID: CAM3SWZTc-yCmMw5DORQ1n5srYaHV_6RLV92SRGStcLBMfcho4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 7, 2016 at 12:43 PM, Oskari Saarenmaa <os(at)aiven(dot)io> wrote:
> Something like the attached patch? It still modifies the toast_delete API,
> but we could also implement a new speculative-tuple-aware version of it if
> that's a concern.

This looks good. I like what you've done with the toast_delete() API,
personally.

I would like to hear Andres' opinion on whether or not he feels it
okay to "HeapTupleHeaderSetXmin(tp.t_data, InvalidTransactionId)"
TOAST tuples. If we want to go that way, we should update the
defensive code's comments within HeapTupleSatisfiesToast() to
acknowledge the now very real possibility of that code being strictly
necessary and not just defensive.

It also occurs to me that logical decoding might be affected by the
fact that heap_abort_speculative() is used for TOAST tuples. It looks
fine to me, because while we ignore super deletion from within
DecodeDelete(), it's also true that we're not interested in TOAST
deletion in general from within ReorderBufferCommit(). I'd definitely
like to hear a second opinion on that from Andres, though.

--
Peter Geoghegan

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message digoal 2016-07-08 01:28:33 BUG #14234: PostgreSQL consuming large amount of memory for persistent connection
Previous Message Valeria Arregui 2016-07-07 21:50:30 pg admin corta resultado