|From:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <fujii(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: stopgap fix for signal handling during restore_command|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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.
Amazon Web Services: https://aws.amazon.com
|Next Message||Tom Lane||2023-03-01 22:59:45||Re: Making empty Bitmapsets always be NULL|
|Previous Message||Andres Freund||2023-03-01 22:35:15||Re: refactoring relation extension and BufferAlloc(), faster COPY|