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 |
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. |