On Tue, Nov 24, 2015 at 7:00 PM, Marco Nenciarini <marco.nenciar...@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 <cr...@2ndquadrant.com> wrote: >>> On 10 November 2015 at 01:47, Marco Nenciarini >>> <marco.nenciar...@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? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers