Thread: 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:
TransactionIdGetTopTransactionId(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. +