Re: Improve checks for GUC recovery_target_xid - Mailing list pgsql-hackers

From David Steele
Subject Re: Improve checks for GUC recovery_target_xid
Date
Msg-id 04a5991a-829d-435e-8ff6-e898197e31dc@pgbackrest.org
Whole thread Raw
In response to Re: Improve checks for GUC recovery_target_xid  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 3/4/26 23:19, Fujii Masao wrote:
> On Thu, Mar 5, 2026 at 12:41 AM Fujii Masao <masao.fujii@gmail.com> wrote:
>> My earlier comment was based on my misunderstanding. I thought that only
>> 32-bit transaction IDs were allowed for recovery_target_xid, and therefore
>> values larger than 2^32 should be rejected.
>>
>> However, recovery_target_xid currently accepts both 32-bit XIDs and 64-bit
>> full transaction IDs (epoch + 32-bit XID). When a 64-bit value is specified,
>> only the 32-bit XID portion is used as the recovery target.
>> Given this behavior, your change seems to make sense.
> 
> I'm tempted to clarify this behavior by adding something like
> the following text to the description of recovery_target_xid
> in config.sgml...:
> 
> -------------------------------
> The value can be specified as either a 32-bit transaction ID or a 64-bit
> transaction ID (consisting of an epoch and a 32-bit ID), such as the value
> returned by pg_current_xact_id(). When a 64-bit transaction ID is provided,
> only its 32-bit transaction ID portion is used as the recovery target.
> For example, the values 4294968296 (epoch 1) and 8589935592 (epoch 2)
> both refer to the same 32-bit transaction ID, 1000.
> 
> The effective transaction ID (the 32-bit portion) must be greater than
> or equal to 3.
> -------------------------------

+1. I added this to the v3 patch.

Regards,
-David



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Improve checks for GUC recovery_target_xid
Next
From: Amit Kapila
Date:
Subject: Re: [19] CREATE SUBSCRIPTION ... SERVER