"Tom Lane" <[EMAIL PROTECTED]> writes: > I'm not sure how many people noticed this -patches discussion: > http://archives.postgresql.org/pgsql-patches/2008-03/msg00282.php > so I'm reposting on -hackers. > > The conclusion I drew from that thread is that we should send the text > of all queries involved in a deadlock to the server log, regardless > of session ownership, while reverting the client-side display to what > it's been historically.
Modulo including a HINT suggesting looking at the log I concur. I can't actually come up with an unassailable argument for it but I would definitely be more comfortable. I'm picturing an environment like a web server database where the database user doesn't actually represent the security fault lines. Batch jobs, back-end administration, and web queries are quite likely being run as the same user and security being handled by the application. In such a configuration you would normally have the web front-end configured not to show errors at all to avoid leaking even the front-end queries -- that's why I say I can't see an unassailable argument. But if you *don't* configure it to do that the worst you would expect is for it to leak the web front-end queries, not random administrative queries which happen to be running at the same time. I wonder how useful it is to output process ids at all. And for that matter whether leaking process ids alone could be considered a security risk. Perhaps the error message should just output enough detail to uniquely identify the log message. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning - Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
