Re: pgsql: Fix misplaced right paren bugs in pgstatfuncs.c. - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Fix misplaced right paren bugs in pgstatfuncs.c.
Date
Msg-id 29462.1388279697@sss.pgh.pa.us
Whole thread Raw
In response to pgsql: Fix misplaced right paren bugs in pgstatfuncs.c.  (Kevin Grittner <kgrittn@postgresql.org>)
List pgsql-committers
Kevin Grittner <kgrittn@postgresql.org> writes:
> Fix misplaced right paren bugs in pgstatfuncs.c.
>
> The bug would only show up if the C sockaddr structure contained
> zero in the first byte for a valid address; otherwise it would
> fail to fail, which is probably why it went unnoticed for so long.

Just for the sake of the archives: I think this analysis is wrong.
What we had was equivalent to

     if (memcmp(x, y, 0))

The POSIX spec doesn't actually say in so many words what memcmp
should do for zero length, but a reasonable expectation is that
it should return zero ("equal").  So I think really we're getting
constant false here, independently of what's in the sockaddr.

So for example in pg_stat_get_activity(), the test to see if the address
was all-zero would always fail to fire, and it would then try to see what
the address family was --- and unless the platform had used zero for
AF_INET, AF_INET6, or AF_UNIX, it would then fall through to the "Unknown
address type" case, which would set the output columns to null anyway!
Similarly, in pg_stat_get_backend_client_addr and
pg_stat_get_backend_client_port, a zero ss_family field would lead to
returning NULL which was the intended behavior anyhow.

So the reason that it'd gone unnoticed is that there is in fact no
observable bug.  It's a good catch anyway.

            regards, tom lane


pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Fix whitespace
Next
From: Peter Eisentraut
Date:
Subject: pgsql: Update grammar