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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
