From: | Jean-Christophe Arnu <jcarnu(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: restore_command return code behaviour |
Date: | 2025-07-25 07:35:14 |
Message-ID: | CAHZmTm3o8akBVUGQAZ3VrZrDxupiDXB3Wz1tDemcFU8OtY6XSA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On fri. 25 jul. 2025, 00:01, Jacob Champion <
jacob(dot)champion(at)enterprisedb(dot)com> wrote :
>
> > If you agree, we can suggest a patch for the documentation.
>
> If you've tripped over it, I think we should consider a docs patch.
>
We've spent time on it, guessing it was a return code-driven behaviour,
analysing the code, and finally using debugger to confirm it. If we can
avoid that round trip (and any erroneous analyses stating "it does not
work") for other users, that would be ideal.
>
> To confirm -- you're happy with the behavior as-is?
I'm completely fine with it.
restore_command returning over 128 can be wrapped in a shell script to
catch the given rc *if server shutdown is not the desired behaviour. I
agree that the docs should be as clear as possible about this behaviour
(which may also be an API, that should not be changed).
Here are the places where I think the details should be added :
- GUC documentation [1]
- Backup and Restore [2]
The other mention of restore_command does not involve (or require) return
code details.
If there are no objections, I'll start writing a patch proposal on Monday.
[1]
https://www.postgresql.org/docs/18/runtime-config-wal.html#GUC-RESTORE-COMMAND
: file doc/src/sgml/config.sgml
[2]
https://www.postgresql.org/docs/16/continuous-archiving.html#BACKUP-PITR-RECOVERY
file: doc/src/sgml/backup.sgml
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2025-07-25 07:49:14 | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |
Previous Message | shveta malik | 2025-07-25 07:06:59 | Re: Conflict detection for update_deleted in logical replication |