RE: pg_recvlogical requires -d but not described on the documentation

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Ashutosh Bapat' <ashutosh.bapat.oss@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-02-21T08:55:11Z
Lists: pgsql-hackers

Attachments

Dear Ashutosh,

Thanks for the reply.

> > ISTM the inconsistency is introduced since the initial commit. I think they should
> be unified either
> > 1) update the doc or 2) accept when -d is not specified. Personally, I like 2nd
> approach, pg_recvlogical
> > can follow the normal connection rule. I.e.,
> >
> 
> Given that the discrepancy has survived so long, it seems that users
> always pass -d. And to some extent, requiring users to specify a
> database instead of defaulting to one is safer practice. This avoids
> users fetching changes from unexpected database/slot and cause further
> database inconsistencies on the receiver side. I would just fix
> documentation in this case.

Something like attached, right? The fact that everyone has been set -d option
may be strong.

> > a) Use PGDATABASE if specified
> > b) Check 'U' and PGUSER and use it if specified
> > c) Otherwise use the current OS user name
> 
> If we want to go this route, it will be good to unify the treatment of
> -d option at one place in code and reuse it everywhere. Thanks to your
> investigations, we are seeing too many descripancies in -d option
> being used in many utilities. Fixing all at once would be good. Also
> it will be good to similarly unify documentation by writing -d
> documentation at only place and reusing it everywhere. But I don't
> know whether our documentation allows modularization and code-reuse.

Hmm, unify the treatment seems clean, but it may break current connection rules
for some application. I'm not sure now this is helpful for users.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Commits

  1. Allow pg_recvlogical --drop-slot to work without --dbname.

  2. doc: Clarify required options for each action in pg_recvlogical.

  3. Refactor replication connection code of various pg_basebackup utilities.