From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment |
Date: | 2007-08-29 19:58:49 |
Message-ID: | 46D5CFF9.8080009@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-08-29 20:18:31 | Re: [HACKERS] Contrib modules documentation online |
Previous Message | Florian G. Pflug | 2007-08-29 19:50:28 | Re: Representation of ResourceOwnerIds (transient XIDs) in system views (lazy xid assignment) |