Robert Haas <robertmh...@gmail.com> writes: > On Sat, Jan 16, 2021 at 3:21 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> (Personally, I think this whole patch fails the safety-vs-usefulness >> tradeoff, but I expect I'll get shouted down.)
> What do you see as the main safety risks here? The thing that is scaring me the most is the "broadcast" aspect. For starters, I think that that is going to be useless in the field because of the likelihood that different backends' stack traces will get interleaved in whatever log file the traces are going to. Also, having hundreds of processes spitting dozens of lines to the same place at the same time is going to expose any little weaknesses in your logging arrangements, such as rsyslog's tendency to drop messages under load. I think it's got security hazards as well. If we restricted the feature to cause a trace of only one process at a time, and required that process to be logged in as the same database user as the requestor (or at least someone with the privs of that user, such as a superuser), that'd be less of an issue. Beyond that, well, maybe it's all right. In theory anyplace that there's a CHECK_FOR_INTERRUPTS should be okay to call elog from; but it's completely untested whether we can do that and then continue, as opposed to aborting the transaction or whole session. I share your estimate that there'll be small-fraction-of-a-percent hazards that could still add up to dangerous instability if people go wild with this. regards, tom lane