Re: pg_receivexlog: spurious error message connecting to 9.3

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company