Bruce Momjian <maillist@candle.pha.pa.us> writes:
> OK, sure, pass the pid. However, one problem is that the postmaster
> does not know the pid until after it forks the backend, so if you want
> to send the pid with the cancel key, you will have to send the pid from
> the backend.
Ah, I see: you were planning to send the cancel authorization data to
the FE as part of the AuthenticationOK message. I was assuming it
should be sent by the backend as part of backend startup.
It could be done either way I suppose. The transmission of the cancel
key to the backend is essentially free (see my recent patch), so really
it boils down to whether we'd rather add version-dependent fields to
AuthenticationOK or just add a whole new message type.
> Also, the odds of two backends have the same cancel key, when random
> returns a long() is so astonomically small, that I am willing to live
> with the risk, to take the advantage of cleaner, more modular code.
It would only take a few more lines to make it safe: generate a key,
check for a duplicate in the list of active backends, repeat if there
is a duplicate. However I think that using PID+key is better, because
it makes it that much harder for an attacker to guess a valid cancel
request.
regards, tom lane
