Re: Reinitialize stack base after fork (for the benefit of rr)?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reinitialize stack base after fork (for the benefit of rr)?
Date: 2020-03-27 20:39:54
Message-ID: 20200327203954.hoh6jnfa2cibbaii@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-03-27 14:59:56 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2020-03-27 14:34:56 -0400, Tom Lane wrote:
> >> Andres Freund <andres(at)anarazel(dot)de> writes:
> >>> Tom, while imo not a fix of the right magnitude here: Are you planning /
> >>> hoping to work again on your postmaster latch patch?
>
> >> Um ... -ESWAPPEDOUT. What are you thinking of?
>
> > https://postgr.es/m/18193.1492793404%40sss.pgh.pa.us
>
> Oh, I thought we'd dropped that line of thinking in favor of trying
> to not do work in the postmaster signal handlers (i.e. I thought *you*
> were pushing this forward, not me).

Hm - the way I imagine that to work is that we'd do a SetLatch() in the
various signal handlers and that the main loop would then react to
got_sigchld type variables. But for that we'd need latch support in
postmaster - which I think is pretty exactly what your patch in the
above message does?

Of course there'd need to be several subsequent patches to move work out
of signal handlers into the main loop.

Were you thinking of somehow doing that without using a latch?

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-03-27 20:41:39 Re: pgsql: Provide a TLS init hook
Previous Message David Steele 2020-03-27 20:39:29 Re: backup manifests