Re: stopgap fix for signal handling during restore_command - Mailing list pgsql-hackers

From Andres Freund
Subject Re: stopgap fix for signal handling during restore_command
Date
Msg-id 20230226180029.djk7cth4o3o5doom@awork3.anarazel.de
Whole thread Raw
In response to Re: stopgap fix for signal handling during restore_command  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: stopgap fix for signal handling during restore_command
List pgsql-hackers
Hi,

On 2023-02-25 14:06:29 -0800, Nathan Bossart wrote:
> On Sat, Feb 25, 2023 at 11:52:53AM -0800, Andres Freund wrote:
> > I think I opined on this before, but we really ought to have a function to do
> > some minimal signal safe output. Implemented centrally, instead of being open
> > coded in a bunch of places.
> 
> While looking around for the right place to put this, I noticed that
> there's a write_stderr() function in elog.c that we might be able to use.
> I used that in v9.  WDYT?

write_stderr() isn't signal safe, from what I can tell.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: meson logs environment
Next
From: Tom Lane
Date:
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)