Re: pg_receivexlog: spurious error message connecting to 9.3
От | Fujii Masao |
---|---|
Тема | Re: pg_receivexlog: spurious error message connecting to 9.3 |
Дата | |
Msg-id | CAHGQGwFv0BQk9eYwU3UB5u9R5KPWt0H5wRmRB=PbL9Y_HBPGKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_receivexlog: spurious error message connecting to 9.3 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_receivexlog: spurious error message connecting to 9.3
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: