Re: On-the-fly index tuple deletion vs. hot_standby

On 10.12.2010 19:55, Noah Misch wrote:
> On Thu, Dec 09, 2010 at 09:48:25AM +0000, Simon Riggs wrote:
>> On Fri, 2010-12-03 at 21:43 +0200, Heikki Linnakangas wrote:
>>> Seems reasonable. HeapTupleHeaderAdvanceLatestRemovedXid() will need
>>> similar treatment. Actually, btree_xlog_delete_get_latestRemovedXid()
>>> could just call HeapTupleHeaderAdvanceLatestRemoveXid().
>>
>> Yes, it applies to other cases also. Thanks for the suggestion.
>>
>> Fix committed. Please double-check my work, committed early since I'm
>> about to jump on a plane.
>
> Thanks for making that change. For my understanding, why does the xmin == xmax
> special case in HeapTupleHeaderAdvanceLatestRemoveXid not require !HEAP_UPDATED,
> as the corresponding case in HeapTupleSatisfiesVacuum requires? I can neither
> think of a recipe for triggering a problem as the code stands, nor come up with
> a sound explanation for why no such recipe can exist.

The difference is in the purpose of those two functions.
HeapTupleSatisfiesVacuum decides if a tuple can be safely vacuumed away.
For that purpose, you can't remove a tuple from the middle of an update
chain, even if that tuple was never visible to any other transaction,
because someone might still want to follow the update chain to find the
latest version of the row. HeapTupleHeaderAdvanceLatestRemoveXid is used
to decide if removing a tuple would conflict with in-progress hot
standby queries. For that purpose, you don't need to care about breaking
update chains, as Hot Standby is only used for read-only queries and
read-only queries never follow update chains.

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