Re: Proposal: new ereport option "errdetail_log"

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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