|From:||Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>|
|To:||Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, 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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Jun 29, 2021 at 01:32:26PM +0800, Craig Ringer wrote:
> On Sat, 20 Mar 2021 at 03:46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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.
> I'd be fine with either way.
> I don't expect to be able to get to working on a concrete patch for this
> any time soon, so I'll be leaving it here unless someone else needs to pick
> it up for their extension work. The in-principle agreement is there for
> future work anyway.
There is still a CF entry for this. Should we close it as withdrawn? or
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
|Next Message||Jaime Casanova||2021-10-01 17:31:31||Re: 2021-09 Commitfest|
|Previous Message||Erik Rijkers||2021-10-01 16:19:56||Re: proposal: possibility to read dumped table's name from file|