Re: pg_signal_backend() asymmetry

On Wed, Jun 27, 2012 at 5:38 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> Hi all,
>
> I have one nitpick related to the recent changes for
> pg_cancel_backend() and pg_terminate_backend(). If you use these
> functions as an unprivileged user, and try to signal a nonexistent
> PID, you get:

I think the goal there is to avoid leakage of the knowledge or
non-knowledge of a given PID existing once it is deemed out of
Postgres' control. Although I don't have a specific attack vector in
mind for when one knows a PID exists a-priori, it does seem like an
unnecessary admission on the behalf of other programs.

Also, in pg_cancel_backend et al, PID really means "database session",
but as-is the marrying of PID and session is one of convenience, so I
think any message that communicates more than "that database session
does not exist" is superfluous anyhow. Perhaps there is a better
wording for the time being that doesn't implicate the existence or
non-existence of the PID?

--
fdr