On Wed, Jun 27, 2012 at 5:38 PM, Josh Kupershmidt <schmi...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
