Re: stopgap fix for signal handling during restore_command

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: stopgap fix for signal handling during restore_command
Дата
Msg-id 20230226201227.cner3cdicropu4q5@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: stopgap fix for signal handling during restore_command  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: stopgap fix for signal handling during restore_command  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
Hi,

On 2023-02-26 11:39:00 -0800, Nathan Bossart wrote:
> 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().

Partially I just want something that can easily be searched for, that can have
comments attached to it documenting why what it is doing is safe.

It'd not be a huge amount of work to have a slow and restricted string
interpolation support, to make it easier to write messages. Converting floats
is probably too hard to do safely, and I'm not sure %m can safely be
supported. But basic things like %d would be pretty simple.

Basically a loop around the format string that directly writes to stderr using
write(), and only supports a signal safe subset of normal format strings.

Greetings,

Andres Freund



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

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