Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH] - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]
Date
Msg-id F39699C0-47DC-4E81-A059-E8990E4F37C0@phlo.org
Whole thread Raw
In response to Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
On Dec14, 2010, at 22:34 , Florian Pflug wrote:
> For non-assert-enabled builds, the only effect of the patch is thus to
> consistently return InvalidTransactionId if the crosscheck snapshot turns
> HeapTupleMayBeUpdated into HeapTupleUpdated. Which certainly seems to be
> an improvement over sometimes returning InvalidTransactionId, sometimes
> a locker's xid, and sometime's a multi-xid.

I've updated the patch to explain that in the comments above heap_update()
and heap_delete(). I've taken a brief look at the callers of these functions,
but fail to see how to improve things there. Things work currently because
crosschecking is only used in serializable mode, while the tuple's xmax is
only required in read committed mode to double-check the tuple chain when
following the ctid pointers. But the API doesn't enforce that at all :-(

I'm not willing to clean that mess up, since the serializable lock consistency
patch changes all these areas, *and* makes the cleanup easier by getting rid
of the crosscheck snapshot entirely.

I still believe that applying this patch now is worth it, for the reasons
already explained, but in the end that's obviously something for a committer
to decide.

Patch with updated comments attached.

best regards,
Florian Pflug

Attachment

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: ALTER TABLE ... REPLACE WITH
Next
From: Robert Haas
Date:
Subject: Re: WIP patch for parallel pg_dump