Neil Conway <neilc@samurai.com> writes:
> On adapting the code to just send the client address in the BE start
> message, I'm not actually sure this is the right way to go. The problem
> is that stats messages are unordered -- so we might receive, say, an
> activity message for a backend before we receive its BE startup message.
I think this argument is a red herring ... or at least it leads in a
direction I find unacceptable. We are already transmitting three more
fields than necessary in every MsgHdr --- PID, database OID, and user ID
--- and it will only get worse if we go down this path. I would have to
ask what is the point of the BESTART message at all, if the design
requires retransmitting everything it could possibly carry in every
subsequent message.
It is true that the pgstat message mechanism is unreliable, and
therefore you will sometimes not find out things you would like to find
out. But adding more overhead onto every message is not the way to
improve that situation; it will make it worse by increasing the
bandwidth demand. I think we should just accept that we will sometimes
have to return NULL for these items because we missed a message.
(And if it wasn't clear, I'm in favor of stripping the msghdr down.
The header should be about 8 bytes not 24, let alone 40+ which is
what it would have to be to handle IPv6 client addresses the way
you suggest.)
regards, tom lane
