Magnus Hagander wrote:
> I guess that's from not reading things carefully enough. I looked for
> where "backend pid" was transmitted, because I thought that would be a
> good place to put it.
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.
That means pg_stat_get_backend_client_addr() might be invoked for a
backend the stats collector knows about, but doesn't know its client
address. We could invent a sentinel value for this case and return SQL
NULL, but it seems quite ugly (since the backend entry struct stores
SockAddr, not SockAddr *)-- simpler to just send the client address with
every message, I guess.
> Which might bring up the question, why are things like the backend
> pid sent in msghdr and not in bestart?
If not for the situation outlined above, we could move at least m_userid
out of the message header.
> That said, I'm not sure that the startup time specifically is sensitive,
> no. No real rason to hide that, but I'm not sure I buy the argument
> "considering since it's available via ps(1)" ;-)
Yeah, that's true, the ps(1) argument is invalid. May as well limit
access to it...
> I first did it with NULL,NULL, before I realised I could not make just
> that distinction. I guess in theory we could return 0.0.0.0 or
> 255.255.255.255 (similar for IPv6 of course, don't know offhand what
> that would be), btu that seems at least as ugly.
> Another way would be to have yet another column that would be "client
> address type", but given the options I think the current way is probably
> the least ugly.
Yeah, I agree -- I guess we should stick with the current convention.
-Neil