Re: pg_receivexlog: spurious error message connecting to 9.3

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-11-24 13:32:27
Message-ID: CAHGQGwFXS6d8GhdEgWZUuo6DJWvN_Bg5KF5hh6hdm-Ys66U2gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2015-11-24 13:46:56 Re: Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)
Previous Message Ants Aasma 2015-11-24 13:10:30 Re: parallelism and sorting