Postgres Pro
Downloads
Home   >   mailing lists

Re: Usage of epoch in txid_current - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Usage of epoch in txid_current
Date
Msg-id CAMkU=1xLb7105EaAEpSyCs7RbHPZm_nZw7qMkvJp3h4_FeZrZA@mail.gmail.com
Whole thread Raw
In response to Re: Usage of epoch in txid_current  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Usage of epoch in txid_current  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Tree view
On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro <thomas.munro@gmail.com> wrote:
On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Once we have the FullTransactionId type and basic macros in place, I'm
> sure we could tidy up a bunch of code by using them.

Thanks for the reviews!  Pushed.

I think that this might be broken.

We have this change:

@@ -73,7 +75,8 @@ GetNewTransactionId(bool isSubXact)
 
    LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
 
-   xid = XidFromFullTransactionId(ShmemVariableCache->nextFullXid);
+   full_xid = ShmemVariableCache->nextFullXid;
+   xid = XidFromFullTransactionId(full_xid);

But then later on in an little-used code path around line 164:

        /* Re-acquire lock and start over */
        LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
        xid = XidFromFullTransactionId(ShmemVariableCache->nextFullXid);

full_xid does not get updated, but then later on full_xid gets returned in lieu of xid.

Is there a reason that this is OK?

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: to_timestamp docs
Next
From: Jeff Janes
Date:
Subject: Re: Usage of epoch in txid_current