Re: [PATCH] Add Windows support for backtrace_functions (MSVC only) - Mailing list pgsql-hackers

From Jakub Wartak
Subject Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
Date
Msg-id CAKZiRmxzaGwnbuQW5=p+=xHGoZk9YYHPHG1jK3R+Tmr_5vZtkg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, Oct 20, 2025 at 10:40 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Oct 20, 2025 at 10:10:25AM +0200, Jakub Wartak wrote:
> > Cool, thanks for working on this. Win32 is a bit alien to me, but I've
> > got access to win32 so I've played with the patch a little bit. With
> > simple: SET backtrace_functions = 'typenameType'; CREATE TABLE tab (id
> > invalidtype);
>
> Perhaps it would be possible to add some WIN32-specific tests that
> check some log patterns based on the backtraces printed?  (I have not
> read the patch in details, just an idea while passing by.)

Hi Michael,

thanks for stepping in;  It looks like the original 71a8a4f6e3654 had
no tests and sadly the simpler idea - even lowest client_min_messages
settings do not make it possible to send the backtrace log to the
frontend (send_message_to_server_log() logs edata->backtrace, but
send_message_to_frontend() does not).

Also is it worth it to test that setting backtrace_funciton=FOO really
emits .*FOO.* in log message cross-platform way?

Because we would have to accept at least 3 valid results 'not
supported' (e.g. mingw) + 'FOO' + what if just the address is returned
without function name due to use of some wild compiler options? Just
an idea, maybe just setting backtrace_funcitons and *ignoring* output
in log, but proving the server did not crash afterwards would be also
considered as acceptable? (and have a better testing surface that we
have today), but from a different angle it might look like
bloatware...

-J.



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Use CompactAttribute more often, when possible
Next
From: Laurenz Albe
Date:
Subject: Re: doc: create table improvements