From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivexlog: spurious error message connecting to 9.3 |
Date: | 2015-12-07 14:37:44 |
Message-ID: | CAHGQGwFv0BQk9eYwU3UB5u9R5KPWt0H5wRmRB=PbL9Y_HBPGKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 25, 2015 at 11:34 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Nov 24, 2015 at 8:32 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Nov 24, 2015 at 7:00 PM, Marco Nenciarini
>> <marco(dot)nenciarini(at)2ndquadrant(dot)it> wrote:
>>> Hi Robert,
>>>
>>> On 17/11/15 20:10, Robert Haas wrote:
>>>> On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>>>>> On 10 November 2015 at 01:47, Marco Nenciarini
>>>>> <marco(dot)nenciarini(at)2ndquadrant(dot)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
Attachment | Content-Type | Size |
---|---|---|
dbname-warning-fix-fujii.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stas Kelvich | 2015-12-07 14:47:54 | Re: Cube extension kNN support |
Previous Message | Stas Kelvich | 2015-12-07 14:05:31 | Re: Tsvector editing functions |