| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | David Steele <david(at)pgmasters(dot)net>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
| Subject: | Re: [PATCH] ProcessInterrupts_hook |
| Date: | 2021-03-19 19:46:08 |
| Message-ID: | 4156999.1616183168@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Mar 19, 2021 at 3:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm not very comfortable about the idea of having the postmaster set
>> child processes' latches ... that doesn't sound terribly safe from the
>> standpoint of not allowing the postmaster to mess with shared memory
>> state that could cause it to block or crash. If we already do that
>> elsewhere, then OK, but I don't think we do.
> It should be unnecessary anyway. We changed it a while back to make
> any SIGUSR1 set the latch ....
Hmm, so the postmaster could send SIGUSR1 without setting any particular
pmsignal reason? Yeah, I suppose that could work. Or we could recast
this as being a new pmsignal reason.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2021-03-19 20:06:40 | Re: [PATCH] Identify LWLocks in tracepoints |
| Previous Message | Robert Haas | 2021-03-19 19:44:34 | Re: [HACKERS] Custom compression methods |