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