Re: Reinitialize stack base after fork (for the benefit of rr)? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reinitialize stack base after fork (for the benefit of rr)?
Date
Msg-id 20200327203954.hoh6jnfa2cibbaii@alap3.anarazel.de
Whole thread Raw
In response to Re: Reinitialize stack base after fork (for the benefit of rr)?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2020-03-27 14:59:56 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2020-03-27 14:34:56 -0400, Tom Lane wrote:
> >> Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: backup manifests
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Provide a TLS init hook