>
> I see no good reason to believe that the signal handler issue is the only
> one. Even if it is,
> not being able to call any postgres infrastructure is a pretty huge
> handicap.
>
(changed emails to get rid of the nasty employer notice...)
It's at least a workable handicap that I'm happy to
On Thu, Jul 30, 2020 at 2:55 PM Tom Lane wrote:
> > Why not? Our answer to threading inside functions has been, for quite a
> > while, that it's kinda ok if the threads never call into postgres and
> > can never escape the lifetime of a function. But that's not actually
> > really safe due to the
Andres Freund writes:
> On 2020-07-28 21:52:20 -0400, Tom Lane wrote:
>> TBH, though, I do not buy this argument for a millisecond. I don't
>> think that anything is going to come out of multithreading a bgworker
>> but blood and tears. Perhaps someday we'll make a major push to
>> make the back
Hi,
On 2020-07-28 21:52:20 -0400, Tom Lane wrote:
> >> The rationale here is that as far as I can tell this is the *only* blocker
> >> to using multithreaded code in a BGWorker which can't be avoided by
> >> adhering to strict code rules (eg: no PG calls from non-main threads, no
> >> interacti
Hi,
On 2020-07-29 13:41:02 +1200, Thomas Munro wrote:
> One practical problem with this change is that some systems have a
> stub definition of pthread_sigmask() that does nothing, when you don't
> link against the threading library. Realistically, most *useful*
> builds of PostgreSQL bring it in
> We need some kind of concrete plan for what is a
> usable amount of functionality and what has to be done to get it.
>
This is exactly the type of discussion I'm after.
I'll start.
A usable amount of functionality would be the ability to start threads from:
- a background worker
These cas
Thomas Munro writes:
> On Thu, Jul 2, 2020 at 6:39 PM James Sewell wrote:
>> The patch replaces sigprocmask with pthread_sigmask. They have identical
>> APIs ("[pthread_sigmask] shall be equivalent to sigprocmask(), without the
>> restriction that the call be made in a single-threaded process"[
On Thu, Jul 2, 2020 at 6:39 PM James Sewell wrote:
> The patch replaces sigprocmask with pthread_sigmask. They have identical APIs
> ("[pthread_sigmask] shall be equivalent to sigprocmask(), without the
> restriction that the call be made in a single-threaded process"[1])
-#define PG_SETMASK(ma
Hackers,
In the hope of this not being derailed by larger/more unpopular pieces of
work, I'm attaching a tiny patch which I don't believe will have any
negative impact - but will remove one blocker for $subject (sigprocmask
usage is "unspecified" in multithreaded code [1]).
The patch replaces *si
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 Jav
Chapman Flack 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
On 06/23/20 22:13, Tom Lane wrote:
> 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.
...
I'm sure now that I shouldn't have mentioned (1) - muddied wate
Andres Freund 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 s
Hi,
On 2020-06-23 21:50:26 -0400, Chapman Flack wrote:
> On 06/23/20 21:44, Andres Freund wrote:
>
> > I think that's way harder than what you make it sound here. The locking
> > for shm_mq doesn't really work inside a process. In contrast to the
> > single threaded case something like a volatile
On 06/23/20 21:44, Andres Freund wrote:
> I think that's way harder than what you make it sound here. The locking
> for shm_mq doesn't really work inside a process. In contrast to the
> single threaded case something like a volatile write to
> ParallelMessagePending doesn't guarantee much, because
Hi,
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. There
>is already support in core to forward messages from parallel workers:
>the worker signals the lead process after adding a message to a shm_mq
>referenced
On 06/22/20 23:38, Tom Lane wrote:
> bgworkers, or you could dispatch the threaded work to a non-Postgres-ish
> process as PL/Java does. The only advantage I can see of doing work in a
> process that's not at arm's-length is to have access to PG computational
> or IPC facilities, and none of that
On Tue, 23 Jun 2020 at 17:26, Konstantin Knizhnik
wrote:
> On 23.06.2020 10:15, James Sewell wrote:
>
> Using multithreading in bgworker is possible if you do not use any
>> Postgres runtime inside thread procedures or do it in exclusive critical
>> section.
>> It is not so convenient but possibl
On 23.06.2020 10:15, James Sewell wrote:
Using multithreading in bgworker is possible if you do not use any
Postgres runtime inside thread procedures or do it in exclusive
critical
section.
It is not so convenient but possible. The most difficult thing
from my
point
On Tue, 23 Jun 2020 at 17:15, James Sewell
wrote:
> Using multithreading in bgworker is possible if you do not use any
>> Postgres runtime inside thread procedures or do it in exclusive critical
>> section.
>> It is not so convenient but possible. The most difficult thing from my
>> point of view
> Using multithreading in bgworker is possible if you do not use any
> Postgres runtime inside thread procedures or do it in exclusive critical
> section.
> It is not so convenient but possible. The most difficult thing from my
> point of view is error reporting.
>
Happy to be proved wrong, but I
threading in bgworkers (or any other
backend process) is "we don't support it; if you try it and it breaks,
which it likely will, you get to keep both pieces". I'm not sure that
there's any merit in making small dents in that policy. I suspect that
at some point, somebody will tr
sion going.
>
> I think the short answer about threading in bgworkers (or any other
> backend process) is "we don't support it; if you try it and it breaks,
> which it likely will, you get to keep both pieces".
I'm hoping that from this a set of rules rather t
RC the other day -
> which I
> > know is a frowned upon topic - and just wanted to frame the same
> questions
> > here and hopefully get a discussion going.
>
> I think the short answer about threading in bgworkers (or any other
> backend process) is "we don't su
James Sewell writes:
> I was talking about PostgreSQL and threading on IRC the other day - which I
> know is a frowned upon topic - and just wanted to frame the same questions
> here and hopefully get a discussion going.
I think the short answer about threading in bgworkers (or any othe
Hi hackers,
I was talking about PostgreSQL and threading on IRC the other day - which I
know is a frowned upon topic - and just wanted to frame the same questions
here and hopefully get a discussion going.
On IRC RhodiumToad offered the following advice (after a standard there be
dragons here dis
26 matches
Mail list logo
