| From: | James Sewell <james(dot)sewell(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, James Sewell <james(dot)sewell(at)jirotech(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Threading in BGWorkers (!) |
| Date: | 2020-07-31 05:29:48 |
| Message-ID: | CAJe2zgNXYFdgRtNNNCofyJZ9LB5N3bEm-NS8Jz5s3ntYv2uSPw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> 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 deal with.
I can say with 100% confidence that people coming from non C languages will
be using threading in Postgres backends as interop matures (and it's
happening fast now). A lot of the time they won't even know they are using
threads as it will be done by libraries they make use of transparently.
Let's help them to avoid unsafe code now, not wait until they show up on
this list with a critical failure and tap at the big sign that says "NO
THREADING".
- james
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-07-31 05:34:59 | Re: Fix minor source code comment mistake |
| Previous Message | imai.yoshikazu@fujitsu.com | 2020-07-31 05:23:02 | RE: [Proposal] Add accumulated statistics for wait event |