Re: Improve checks for GUC recovery_target_xid

From: David Steele <david(at)pgbackrest(dot)org>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve checks for GUC recovery_target_xid
Date: 2026-03-05 03:40:44
Message-ID: c2e97e35-1227-4351-8faa-fa95208f6cf9@pgbackrest.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/4/26 22:41, Fujii Masao wrote:
>
> Regarding the regression test, if the purpose is to verify the GUC hook
> for recovery_target_xid, it might be simpler to test whether
> "ALTER SYSTEM SET recovery_target_xid TO ..." succeeds or fails as expected
> as follows, rather than starting the server with that setting. That said,
> since recovery_target_timeline is already tested in a similar way, I understand
> why you followed the same pattern here. So I'm ok with the current approach.

I wrote the tests for recovery_target_timeline but I was not too
satisfied with them because starting Postgres is fairly expensive.

>
> my ($result, $stdout, $stderr) = $node_primary->psql('postgres',
> "ALTER SYSTEM SET recovery_target_xid TO 'bogus'");
> like(
> $stderr,
> qr/is not a valid number/,
> "invalid recovery_target_xid (bogus value)");
>
> If we think it's better to use ALTER SYSTEM SET for testing invalid
> recovery_target_xxx settings to keep the regression tests simpler,
> we can revisit this later and address it in a separate patch.

I've updated the patch to do it this way. Not only is it faster but you
get a better message when the expected value is incorrect.

I can update the tests for recovery_target_timeline in a separate patch.

Regards,
-David

Attachment Content-Type Size
recovery-target-xid-v3.patch text/plain 5.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2026-03-05 03:46:02 Re: Improve checks for GUC recovery_target_xid
Previous Message wenhui qiu 2026-03-05 03:40:13 Re: Convert NOT IN sublinks to anti-joins when safe