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

From Nathan Bossart
Subject Re: stopgap fix for signal handling during restore_command
Date
Msg-id 20230301224751.GA1823946@nathanxps13
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  (Andres Freund <andres@anarazel.de>)
Re: stopgap fix for signal handling during restore_command  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Feb 28, 2023 at 08:36:03PM -0800, Nathan Bossart wrote:
> On Sun, Feb 26, 2023 at 12:12:27PM -0800, Andres Freund wrote:
>> 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.
> 
> Got it, thanks.  I will try to put something together along these lines,
> although I don't know if I'll pick up the interpolation support in this
> thread.

Here is an attempt at adding a signal safe function for writing to STDERR.

I didn't add support for format strings, but looking ahead, I think one
challenge will be avoiding va_start() and friends.  In any case, IMO format
string support probably deserves its own thread.

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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: refactoring relation extension and BufferAlloc(), faster COPY
Next
From: Tom Lane
Date:
Subject: Re: Making empty Bitmapsets always be NULL