Re: Threading in BGWorkers (!) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Threading in BGWorkers (!)
Date
Msg-id 2177676.1592968127@sss.pgh.pa.us
Whole thread Raw
In response to Re: Threading in BGWorkers (!)  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: Threading in BGWorkers (!)  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> On 06/23/20 22:13, Tom Lane wrote:
>> 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?

> I think it could be adequate for a lot of them.

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.  It happens to be
okay for NOTIFY, because that's reporting an outside event that
did occur regardless of the local transaction's success ... but
really, how many use-cases does that argument apply to?

I'm not trying to be completely negative here, but I think these
issues are a lot harder than they might seem at first glance.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Threading in BGWorkers (!)
Next
From: Justin Pryzby
Date:
Subject: Re: Default setting for enable_hashagg_disk