On Wed, Nov 25, 2015 at 11:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Nov 24, 2015 at 8:32 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Tue, Nov 24, 2015 at 7:00 PM, Marco Nenciarini
>> <marco.nenciarini@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 <craig@2ndquadrant.com> wrote:
>>>>> On 10 November 2015 at 01:47, Marco Nenciarini
>>>>> <marco.nenciarini@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