Re: pg_createsubscriber --dry-run logging concerns
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Peter Smith <smithpb2250@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-01T10:37:20Z
Lists: pgsql-hackers
On 2025-Oct-01, Peter Smith wrote:
> (code below may not work; it's just for illustrative purposes)
>
> #define pg_log_info_checkdry(...) do {\
> if (dry_run)\
> pg_log_generic(PG_LOG_INFO, PG_LOG_PRIMARY, "[dry-run NOP]" __VA_ARGS__);\
> else;\
> pg_log_generic(PG_LOG_INFO, PG_LOG_PRIMARY, __VA_ARGS__);\
> } while (0);
I like this kind of idea best. However I think it might be better to do
it the other way around: have the normal pg_log_info() check dry_run,
and have a special one for the messages that are to be identical in
either mode. I'm not sure how difficult this is to implement, though.
pg_subscriber is not the only program with a dry-run mode; it looks like
pg_archiveclean, pg_combinebackup, pg_resetwal, pg_rewind have one. Is
it worth maybe doing something at the common/logging.c level rather than
specifically pg_createsubscriber?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
[…] indem ich in meinem Leben oft an euch gedacht, euch glücklich zu machen. Seyd es!
A menudo he pensado en vosotros, en haceros felices. ¡Sedlo, pues!
Heiligenstädter Testament, L. v. Beethoven, 1802
https://de.wikisource.org/wiki/Heiligenstädter_Testament
Commits
-
Split dry-run messages into primary and detail
- 36b1a1e826ea 19 (unreleased) landed
- e3b5817c8b89 master landed
-
Log a note at program start when running in dry-run mode
- c05dee191125 19 (unreleased) landed
-
Use USECS_PER_SEC from datatype/timestamp.h
- ad1581d7feae 19 (unreleased) landed
-
Remove WaitPMResult enum in pg_createsubscriber
- f242dbcede9c 19 (unreleased) landed
-
pg_createsubscriber: reword dry-run log messages
- c25314d5364e 18.1 landed
- 2648eab3779b 19 (unreleased) landed