Re: stopgap fix for signal handling during restore_command

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: stopgap fix for signal handling during restore_command
Дата
Msg-id 20230226193900.GA1248604@nathanxps13
обсуждение исходный текст
Ответ на Re: stopgap fix for signal handling during restore_command  (Andres Freund <andres@anarazel.de>)
Ответы Re: stopgap fix for signal handling during restore_command  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Sun, Feb 26, 2023 at 10:00:29AM -0800, Andres Freund wrote:
> 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.

*facepalm*  Sorry.

What precisely did you have in mind?  AFAICT you are asking for a wrapper
around write().

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)