Re: BUG #16780: Inconsistent recovery_target_xid handling across platforms - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #16780: Inconsistent recovery_target_xid handling across platforms
Date
Msg-id X+F99vxLRK8MXAni@paquier.xyz
Whole thread Raw
In response to Re: BUG #16780: Inconsistent recovery_target_xid handling across platforms  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #16780: Inconsistent recovery_target_xid handling across platforms
List pgsql-bugs
On Mon, Dec 21, 2020 at 04:13:17PM +0900, Michael Paquier wrote:
> In order to make the experience consistent across all platforms, we
> can use pg_strtouint64() for the GUC parsing.  I agree that ignoring
> the high bits can be confusing as recovery would stop once a XID
> matches with a modulo of UINT32_MAX, but beginning to issue an error
> on platforms where unsigned long is 8 bytes could also break existing
> tools.  At the same time, WAL record headers and 2PC state data only
> use 32-bit XIDs, so ignoring the high bits changes nothing at
> recovery (XIDs don't go across more than one epoch in the WAL stream
> AFAIK).  In short, I agree that there is room for improvement here and
> that we should just allow the case to work by replacing the use of
> strtoul() to pg_strtouint64().  I am ready to bet that a lot of users
> setting a target XID rely on the return result of txid_current() or
> pg_current_xact_id() similarly to the test failing here.  And once the
> epoch increments, the problems begin.

So, attached is a patch to make the logic more consistent that I would
like to apply down to 12.  Please let me know if there are any
objections or comments.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #16783: pg_rewind: option -c does not work when configuration files are outside data directory
Next
From: PG Bug reporting form
Date:
Subject: BUG #16788: Postmaster started then shmem_exit(1) is called. database system is starting up