Andres Freund <and...@anarazel.de> writes:
> On 2020-06-23 09:19:36 -0400, Chapman Flack wrote:
>> 1) It would be nice to be able to ereport from an arbitrary thread.
> I think that's way harder than what you make it sound here.
Indeed. Just for starters:
1. elog.c is in itself not-thread-safe, because it uses a static data
structure to track the message being built.
2. It uses palloc, another large pile of not-thread-safe infrastructure.
3. What exactly would the semantics of elog(ERROR) be? You can't make it
something other than "abort the transaction" without mind-boggling levels
of breakage. But how are you going to enforce a transaction abort across
multiple threads? What if one of the other threads reports an independent
error concurrently, or worse tries to COMMIT concurrently?
So that's already two fundamental, and non-trivial, subsystems that have
to be made fully thread-safe before you can get anything off the ground;
plus basic architectural issues to be settled. I imagine that somebody
will take a run at this at some point, but the idea that it's an easy
problem to bite off seems nonsensical.
I'm not sure whether the other idea
>> It would be nice to be able to also asynchronously set some flag
>> like ExtensionServiceRequested, which could be checked as part of
>> CHECK_FOR_INTERRUPTS or even at more limited times, such as idle.
is much easier. In the barest terms, we already have things like that
(such as NOTIFY interrupts), so it doesn't sound hard at first. The
problem is to figure out whether action X that you wish to do is safe
to do at CHECK_FOR_INTERRUPTS call site Y. The answer is certainly not
always "yes", but how would we build an infrastructure for deciding?
(NOTIFY largely punts on this, by decreeing that it won't do anything
till we reach an idle state. That's surely not adequate for a lot
of likely actions X.)
regards, tom lane
