Re: Usage of epoch in txid_current
От | Jeff Janes |
---|---|
Тема | Re: Usage of epoch in txid_current |
Дата | |
Msg-id | CAMkU=1yUTv-FqR3PeUHzosCQfFxMZPhNGF71HeFdVZO4mzguWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Usage of epoch in txid_current (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
On Sat, May 4, 2019 at 1:34 PM Jeff Janes <jeff.janes@gmail.com> wrote:
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?
Ah, sorry for the noise. I see that this has been fixed already. I wasn't looking at HEAD, or at the other email thread, when I "discovered" this.
Sorry for the noise.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: