Tom Lane wrote:
> I think this argument is a red herring ... or at least it leads in a
> direction I find unacceptable.
I agree -- I was just pointing out the reason that, in the current
design, there is cause to do things as Magnus' original patch did.
> 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.
How about changing the statistics collector so that we only include a
row in the statistics view when we receive the BESTART message? That
would mean the BESTART message could include backend-start metadata
(user ID, database ID, client address), and all other messages would
only need enough header data to identify the backend process they are
associated with (so perhaps backend id and process id).
Using the existing dead-backend hash table, we should be able to
distinguish between the cases of "seen a message for a new backend
before receiving its BESTART" and "seen a message for a dead backend
after we've seen its BETERM".
-Neil