On 06/23/20 23:08, Tom Lane wrote: > I dunno. It's not even adequate for the use-case of reporting an > error, because waiting till after the current transaction commits > is surely not what should happen in that case.
In the case of the kind of exuberantly-threaded language runtime of which Java's an example, most of the threads running at any given time are doing somewhat obscure things that the language runtime knows about but might not be directly relevant to whether your current transaction commits. (The garbage collector thread was my earlier example because it routinely discovers reclaimable things, which can have implications for resources in PG but usually not for whether a commit should succeed.) If you're going to write a function and explicitly use threads in your computation, those are threads you're going to manage, catch exceptions in, and forward those back to the main thread to be ereported at the appropriate time. In other cases where some thread you're but dimly aware of has encountered some problem, generally what happens now is a default message and stacktrace get directly written to the backend's stderr and you don't otherwise find out anything happened. If something doesn't work later because that thread got wedged, then you piece together the story. If the logging_collector is running then at least the stuff written to stderr ends up in the log anyway, though without any log prefix info added. If the collector isn't running, then the messages went somewhere else, maybe the systemd journal, maybe the floor. Regards, -Chap
