txid_current() forces a real xid
Right now, calling txid_current() causes a session to create a
non-virtual xid if not already assigned, so observing the xid creates
it, which seems kind of odd. Is that intended? Here is the C code:
TransactionId
GetTopTransactionId(void)
{
if (!TransactionIdIsValid(TopTransactionStateData.transactionId))
AssignTransactionId(&TopTransactionStateData);
return TopTransactionStateData.transactionId;
}
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
Right now, calling txid_current() causes a session to create a
non-virtual xid if not already assigned, so observing the xid creates
it, which seems kind of odd. Is that intended?
GetTopTransactionId (and friends) should only be called in places where
the intent is to assign an xid if we haven't already got one. I'm not
sure what the use case is for txid_current(), but it's at least
plausible that applications using it would have the same intention.
regards, tom lane
On Mon, Jul 11, 2011 at 5:59 PM, Bruce Momjian <bruce@momjian.us> wrote:
Right now, calling txid_current() causes a session to create a
non-virtual xid if not already assigned, so observing the xid creates
it, which seems kind of odd. Is that intended? Here is the C code:
Yes, it was intentional, the value will be written out.
It could be even called before actual writing statement is run
so returning anything that will become invalid later during
transaction is dangerous.
If you have use-case that requires frequent calling of that function
in read-only transaction, and prefer to see virtual txids
I suggest implementing it as new function.
--
marko
Marko Kreen wrote:
On Mon, Jul 11, 2011 at 5:59 PM, Bruce Momjian <bruce@momjian.us> wrote:
Right now, calling txid_current() causes a session to create a
non-virtual xid if not already assigned, so observing the xid creates
it, which seems kind of odd. ?Is that intended? ?Here is the C code:Yes, it was intentional, the value will be written out.
It could be even called before actual writing statement is run
so returning anything that will become invalid later during
transaction is dangerous.If you have use-case that requires frequent calling of that function
in read-only transaction, and prefer to see virtual txids
I suggest implementing it as new function.
No, I just considered it strange that it assigned a permenant xid by
asking for the value.
I have added a C comment documenting this behavior.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +