Re: Improve checks for GUC recovery_target_xid
David Steele <david@pgbackrest.org>
From: David Steele <david@pgbackrest.org>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Hüseyin Demir <huseyin.d3r@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-05T03:46:02Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve tests for recovery_target_timeline GUC.
- 2007df43332b 19 (unreleased) landed
-
Improve validation of recovery_target_xid GUC values.
- bffd7130e942 19 (unreleased) landed