Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Date
Msg-id 46D5CFF9.8080009@phlo.org
Whole thread Raw
In response to Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> One thought here is that it's not clear that we really need a concept of
>>> transaction-controlled vs not-transaction-controlled xlog records
>>> anymore.
> 
>> I've thinking about keeping XLOG_NO_TRAN, and doing
>> if (!no_tran)
>>    Assert(TransactionIdIsValid(GetCurrentTransactionIdIfAny())
>> in xlog.c as a safety measure.
> 
> Why do you think this is a safety measure?  All that it is checking
> is whether the caller has preserved an entirely useless distinction.
> The real correctness property is that you can't write your XID
> into a heap tuple or XLOG record if you haven't acquired an XID,
> but that seems nearly tautological.

I was confused. I wanted to protect against the case the an XID hits
the disk, but doesn't show up in any xl_xid field, and therefore might
be reused after crash recovery. But of course, to make that happen
you'd have to actually *store* the XID into the data you pass to
XLogInsert, which is kind of hard if you haven't asked for it first.

So, I now agree, XLOG_NO_TRAN should be buried.

greetings, Florian Pflug


pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment)
Next
From: Andrew Dunstan
Date:
Subject: Re: Contrib modules documentation online