On Wed, Nov 25, 2015 at 11:34 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Nov 24, 2015 at 8:32 AM, Fujii Masao <masao.fu...@gmail.com> wrote:
>> On Tue, Nov 24, 2015 at 7:00 PM, Marco Nenciarini
>> <marco.nenciar...@2ndquadrant.it> wrote:
>>> Hi Robert,
>>>
>>> On 17/11/15 20:10, Robert Haas wrote:
>>>> On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer <cr...@2ndquadrant.com>
>>>> wrote:
>>>>> On 10 November 2015 at 01:47, Marco Nenciarini
>>>>> <marco.nenciar...@2ndquadrant.it> wrote:
>>>>>
>>>>>> I've attached a little patch that removes the errors when connected to
>>>>>> 9.3.
>>>>>
>>>>> Looks good to me. No point confusing users.
>>>>>
>>>>> The other callers of RunIdentifySystem are pg_basebackup and
>>>>> pg_receivelogical.
>>>>>
>>>>> pg_basebackup doesn't ask for the db_name (passes null).
>>>>>
>>>>> pg_receivelogical handles it being null already (and if it didn't,
>>>>> it'd die with or without this patch).
>>>>>
>>>>> pg_receivexlog expects it to be null and fails gracefully if it isn't.
>>>>>
>>>>> So this change just removes some pointless noise.
>>>>
>>>> The fprintf(stderr, ...) does not cause a non-local exit, so the
>>>> "else" just after it should be deleted. Otherwise, when that branch
>>>> is taken, *db_name doesn't get initialized at all.
>>>>
>>>> Actually, I'd suggest doing it like the attached instead, which seems
>>>> a bit tighter.
>>>>
>>>
>>> I agree, your patch is better.
>>
>> + else if (PQserverVersion(conn) >= 90400)
>> fprintf(stderr,
>> _("%s: could not identify system: got %d rows and
>> %d fields, expected %d rows and %d or more fields\n"),
>> progname, PQntuples(res), PQnfields(res), 1, 4);
>> }
>>
>> In the above case, PQclear(res) should be called and FALSE should be
>> returned?
>
> Hmm, yeah, it looks like that would be more consistent with what the
> other parts of this function do.
The latest patch has another problem; pg_receivexlog trying to connect to
the PostgreSQL >= 9.4 always reports the following message unexpectedly.
could not identify system: got 1 rows and 4 fields, expected 1 rows
and 4 or more fields
This problem happens because the patch incorrectly treats the case where
IDENTIFY_SYSTEM command returns NULL as database name, as an error case.
Attached is the updated version of the patch, which fixes the problem.
Comments?
Regards,
--
Fujii Masao
diff --git a/src/bin/pg_basebackup/streamutil.c b/src/bin/pg_basebackup/streamutil.c
index 2c963b6..39c616a 100644
--- a/src/bin/pg_basebackup/streamutil.c
+++ b/src/bin/pg_basebackup/streamutil.c
@@ -294,15 +294,21 @@ RunIdentifySystem(PGconn *conn, char **sysid, TimeLineID *starttli,
/* Get database name, only available in 9.4 and newer versions */
if (db_name != NULL)
{
- if (PQnfields(res) < 4)
- fprintf(stderr,
- _("%s: could not identify system: got %d rows and %d fields, expected %d rows and %d or more fields\n"),
- progname, PQntuples(res), PQnfields(res), 1, 4);
+ *db_name = NULL;
+ if (PQserverVersion(conn) >= 90400)
+ {
+ if (PQnfields(res) < 4)
+ {
+ fprintf(stderr,
+ _("%s: could not identify system: got %d rows and %d fields, expected %d rows and %d or more fields\n"),
+ progname, PQntuples(res), PQnfields(res), 1, 4);
- if (PQgetisnull(res, 0, 3))
- *db_name = NULL;
- else
- *db_name = pg_strdup(PQgetvalue(res, 0, 3));
+ PQclear(res);
+ return false;
+ }
+ if (!PQgetisnull(res, 0, 3))
+ *db_name = pg_strdup(PQgetvalue(res, 0, 3));
+ }
}
PQclear(res);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
