On Tue, Jun 21, 2016 at 3:46 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-06-21 15:38:25 -0400, Robert Haas wrote: >> On Tue, Jun 21, 2016 at 1:49 PM, Andres Freund <and...@anarazel.de> wrote: >> >> I'm also a bit dubious that LockAcquire is safe to call in general >> >> with interrupts held. >> > >> > Looks like we could just acquire the tuple-lock *before* doing the >> > toast_insert_or_update/RelationGetBufferForTuple, but after releasing >> > the buffer lock. That'd allow us to do avoid doing the nested locking, >> > should make the recovery just a goto l2;, ... >> >> Why isn't that racey? Somebody else can grab the tuple lock after we >> release the buffer content lock and before we acquire the tuple lock. > > Sure, but by the time the tuple lock is released, they'd have updated > xmax. So once we acquired that we can just do > if (xmax_infomask_changed(oldtup.t_data->t_infomask, > infomask) || > > !TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data), > xwait)) > goto l2; > which is fine, because we've not yet done the toasting.
I see. > I'm not sure wether this approach is better than deleting potentially > toasted data though. It's probably faster, but will likely touch more > places in the code, and eat up a infomask bit (infomask & HEAP_MOVED > == HEAP_MOVED in my prototype). Ugh. That's not very desirable at all. -- Robert Haas EnterpriseDB: 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
