Re: [PATCH] ProcessInterrupts_hook

Поиск
Список
Период
Сортировка
От Jaime Casanova
Тема Re: [PATCH] ProcessInterrupts_hook
Дата
Msg-id 20211001172413.GA12972@ahch-to
обсуждение исходный текст
Ответ на Re: [PATCH] ProcessInterrupts_hook  (Craig Ringer <craig.ringer@enterprisedb.com>)
Ответы Re: [PATCH] ProcessInterrupts_hook  (Craig Ringer <craig.ringer@enterprisedb.com>)
Список pgsql-hackers
On Tue, Jun 29, 2021 at 01:32:26PM +0800, Craig Ringer wrote:
> On Sat, 20 Mar 2021 at 03:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane <tgl@sss.pgh.pa.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.

Hi Craig,

There is still a CF entry for this. Should we close it as withdrawn? or
maybe RwF?

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: 2021-09 Commitfest