From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | pg_createsubscriber --dry-run logging concerns |
Date: | 2025-10-01 02:29:56 |
Message-ID: | CAHut+PsvQJQnQO0KT0S2oegenkvJ8FUuY-QS5syyqmT24R2xFQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Lately, I've been reviewing some pg_createsubscriber patches and have
been tricked by some of the logging.
The pg_createsubscriber has a '--dry-run' option/mode [1]
----------
--dry-run
Do everything except actually modifying the target directory.
----------
I've noticed that the logging in '--dry-run' mode is indistinguishable
from the logging of "normal" run, although functions like
create_publication(), drop_publication(), etc, are NOP in '--dry-run'
mode, because the actual command execution code is skipped. e.g.
if (!dry_run)
{
res = PQexec(conn, str->data);
...
}
~~~
IMO, it's not good to fool people into thinking something has happened
when in fact nothing happened at all. I think the logging of this tool
should be much more explicit wrt when it is/isn't in dry-run mode.
Perhaps like this:
NORMAL
pg_log_info("creating publication \"%s\" in database \"%s\"", ...)
DRY-RUN
pg_log_info("[dry-run] would create publication \"%s\" in database \"%s\"", ...)
~~~
Thoughts?
======
[1] https://www.postgresql.org/docs/current/app-pgcreatesubscriber.html
Kind Regards,
Peter Smith.
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-10-01 02:56:30 | RE: How can end users know the cause of LR slot sync delays? |
Previous Message | Peter Smith | 2025-10-01 00:30:05 | Re: Add support for specifying tables in pg_createsubscriber. |