Re: Hot Standby b-tree delete records review - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Hot Standby b-tree delete records review
Date
Msg-id 4BD00897.1090306@enterprisedb.com
Whole thread Raw
In response to Re: Hot Standby b-tree delete records review  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot Standby b-tree delete records review  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
>> btree_redo:
>>>     /*
>>>      * Note that if all heap tuples were LP_DEAD then we will be
>>>      * returning InvalidTransactionId here. This seems very unlikely
>>>      * in practice.
>>>      */
>> If none of the removed heap tuples were present anymore, we currently
>> return InvalidTransactionId, which kills/waits out all read-only
>> queries. But if none of the tuples were present anymore, the read-only
>> queries wouldn't have seen them anyway, so ISTM that we should treat
>> InvalidTransactionId return value as "we don't need to kill anyone".
> 
> That's not the point. The tuples were not themselves the sole focus,

Yes, they were. We're replaying a b-tree deletion record, which removes
pointers to some heap tuples, making them unreachable to any read-only
queries. If any of them still need to be visible to read-only queries,
we have a conflict. But if all of the heap tuples are gone already,
removing the index pointers to them can'ẗ change the situation for any
query. If any of them should've been visible to a query, the damage was
done already by whoever pruned the heap tuples leaving just the
tombstone LP_DEAD item pointers (in the heap) behind.

Or do we use the latestRemovedXid value for something else as well?

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby b-tree delete records review
Next
From: Simon Riggs
Date:
Subject: Re: Hot Standby b-tree delete records review