Re: Usage of epoch in txid_current

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Subject: Re: Usage of epoch in txid_current
Date: 2019-03-25 14:23:49
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 25/03/2019 12:49, Thomas Munro wrote:
> On Mon, Mar 25, 2019 at 5:01 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> New version attached. I'd like to commit this for PG12.
> Here is a follow-up sketch patch that shows FullTransactionId being
> used in the transaction stack, so you can call eg
> GetCurrentFullTransactionId(). A table access method could use this
> to avoid the need to freeze stuff later (eg zheap).
> I suppose it's not strictly necessary, since you could use
> GetCurrentTransactionId() and infer the epoch by comparing with
> ReadNextFullTransactionId() (now that the epoch counting is reliable,
> due to patch 0001 which I'm repeating again here just for cfbot). But
> I suppose we want to get away from that sort of thing. Thoughts?

Looks good.

I started to write a patch to use XID & epoch in dealing with GiST page
deletions [1], and I really could've used an epoch to go with
RecentGlobalXmin. I presume that would be pretty straightforward to have
with this, too.


- Heikki

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-03-25 14:24:05 Re: Assert failure when validating foreign keys
Previous Message David Fetter 2019-03-25 14:15:33 Re: warning to publication created and wal_level is not set to logical