Re: pgsql: pg_createsubscriber: creates a new logical replica from a standb

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: peter(at)eisentraut(dot)org
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: pg_createsubscriber: creates a new logical replica from a standb
Date: 2024-03-26 05:01:16
Message-ID: 20240326.140116.1116279856046587865.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Hello.

This commit added the following error message:

pg_createsubscriber.c: 375
> pg_fatal("could not access directory \"%s\": %s", datadir,
> strerror(errno));

Although other messages use %s with PQresultErrorMessage(), regarding
this specific message, shouldn't we use %m instead of %s + strerror()?
I'm not sure if that would be better.

pg_createsubscriber.c: 687
> pg_log_error("could not obtain database OID: got %d rows, expected %d rows",
> PQntuples(res), 1);
pg_createsubscriber.c: 1652
> pg_log_error("could not obtain subscription OID: got %d rows, expected %d rows",

In these messages, the second %d is always written as "1 rows",
whereas a similar message correctly uses "1 row".

pg_createsubscriber.c: 561
> pg_log_error("could not get system identifier: got %d rows, expected %d row",
> PQntuples(res), 1);

I think it would be better to change the former instances to "%d row",
or to change both to "1 row". I'd like to go the second way but maybe
we should take the first way following our convention.

pg_createsubscriber.c: 923
> pg_log_error("publisher requires wal_level >= logical");

We discussed this message in relation to commit 801792e528, and
decided to quote "logical" to clarify that it is a string literal. I'd
like to follow the conclusion here, too.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
pg_createsubscriber_message_fixes_v1.patch text/x-patch 1.5 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bharath Rupireddy 2024-03-26 05:43:55 Re: pgsql: Track last_inactive_time in pg_replication_slots.
Previous Message shveta malik 2024-03-26 04:25:19 Re: pgsql: Track last_inactive_time in pg_replication_slots.