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. We could argue separately about whether it's ever really safe to report other-session queries, but in any case the server log will receive a more complete report in general. To implement that we'll need some new feature in elog.c. I propose a new auxiliary function "errdetail_log()" that works exactly like errdetail(), except that the string it produces is reported only to the server log, never to the client. If both errdetail() and errdetail_log() are used then one string goes to the client and the other to the log. The current uses for this are in deadlock reporting and in reporting what objects a user owns when DROP USER fails. The main objection I can think of to this approach is that the two strings will be somewhat redundant, and storing both independently could result in an out-of-memory failure that otherwise wouldn't occur. I'm not too worried about that in the deadlock case, because it's unlikely that you'd have a large number of processes involved in a deadlock, so the duplicative storage of "Process N is blocked by process M" lines really isn't going to amount to much. There's a bit more space at stake in the DROP USER case, but it's still pretty small (since the whole point in the DROP USER case is to limit how much text goes to the client) and in any case I don't foresee people doing DROP USER in low-memory situations. So, while we could arrange the definition in some more complex way to avoid storing duplicate text, I don't really think it's worth the trouble and potential loss of flexibility. Barring objections, I'm going to go ahead and do this now so that we can close the books on Itagaki-san's deadlock reporting patch. I don't want to risk forgetting that we have a security concern to deal with there. regards, tom lane - Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers