Re: [PATCH] Transaction traceability - txid_status(bigint)

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Subject: Re: [PATCH] Transaction traceability - txid_status(bigint)
Date: 2016-08-20 13:46:55
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 20 August 2016 at 21:24, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> Hi all
> Following on from
> bigint txids vs 'xid' type, new txid_recent(bigint) => xid
Ahem. Forgot to squash in a fixup commit. Updated patch of
txid_status(bigint) attachd.

A related patch follows, adding a new txid_current_ifassigned(bigint)
function as suggested by Jim Nasby. It's usefully connected to
txid_status() and might as well be added at the same time.

Since it builds on the same history I've also attached an updated version
of txid_recent(bigint) now called txid_convert_ifrecent(bigint), per the
above-linked thread.

Finally, and not intended for commit, is a useful test function I wrote to
cause extremely rapid xid wraparound, bundled up into a src/test/regress
test case. txid_incinerate() can jump the server about UINT32/2 xids in ~2
seconds if fsync is off, making it handy for testing. Posting so others
can use it for their own test needs later and because it's useful for
testing these patches that touch on the xid epoch.

Craig Ringer
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-Introduce-txid_status-bigint-to-get-status-of-an-xac.patch text/x-patch 15.0 KB
0002-Add-txid_current_ifassigned.patch text/x-patch 4.9 KB
0003-Add-txid_convert_ifrecent-to-get-the-32-bit-xid-from.patch text/x-patch 11.5 KB
0004-Add-txid_incinerate-test-function-for-fast-wrap-arou.patch text/x-patch 15.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-08-20 13:49:56 Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid
Previous Message Michael Paquier 2016-08-20 13:41:32 Re: LSN as a recovery target