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 CAKZiRmzxyNFGQEM=v1KaN3F3xgn1XYN2Udw+ghyT+sVA_impsg@mail.gmail.com
Whole thread Raw
In response to [PATCH] Add Windows support for backtrace_functions (MSVC only)  (Bryan Green <dbryan.green@gmail.com>)
Responses Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
List pgsql-hackers
On Thu, Oct 9, 2025 at 5:50 PM Bryan Green <dbryan.green@gmail.com> wrote:

Hi Bryan!

> I've implemented Windows support for the backtrace_functions configuration parameter using the DbgHelp API. This
bringsWindows debugging capabilities closer to parity with Unix/Linux platforms. 

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);

I've got
    2025-10-20 08:47:25.440 CEST [25700] ERROR:  type "invalidtype"
does not exist at character 22
    2025-10-20 08:47:25.440 CEST [25700] BACKTRACE:
            typenameType+0x86
[C:\git\postgres-master\src\backend\parser\parse_type.c:270]
            transformColumnDefinition+0x1df
[C:\git\postgres-master\src\backend\parser\parse_utilcmd.c:649]
            transformCreateStmt+0x306
[C:\git\postgres-master\src\backend\parser\parse_utilcmd.c:279]
    [..]
            main+0x4f8 [C:\git\postgres-master\src\backend\main\main.c:218]
            __scrt_common_main_seh+0x10c
[D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
            BaseThreadInitThunk+0x17 [0x7ffc5f06e8d7]
            RtlUserThreadStart+0x2c [0x7ffc5ff08d9c]
    2025-10-20 08:47:25.440 CEST [25700] STATEMENT:  CREATE TABLE tab
(id invalidtype);

> Without PDB files, raw memory addresses are shown.

and after removing PDB files, so it's how the real distribution of
Win32 are shipped, it's still showing function names (but MSVC
shouldn't be putting symbols into binaries, right? I mean it's better
than I expected):
    2025-10-20 09:49:03.061 CEST [22832] ERROR:  type "invalidtype"
does not exist at character 22
    2025-10-20 09:49:03.061 CEST [22832] BACKTRACE:
            typenameType+0x86 [0x7ff71e6e3426]
            transformAlterTableStmt+0xb7f [0x7ff71e6e5eef]
            transformCreateStmt+0x306 [0x7ff71e6e78a6]
[..]

meanwhile on Linux:
    2025-10-20 08:49:11.758 CEST [4310] ERROR:  type "invalidtype"
does not exist at character 22
    2025-10-20 08:49:11.758 CEST [4310] BACKTRACE:
            postgres: postgres postgres [local] CREATE
TABLE(typenameType+0x86) [0x560f082eeb06]
            postgres: postgres postgres [local] CREATE
TABLE(+0x36ae37) [0x560f082efe37]
            postgres: postgres postgres [local] CREATE
TABLE(transformCreateStmt+0x386) [0x560f082ef676]
    [..]

Clearly the MSVC version by default seems to be more reliable in terms
of symbols resolution. Anyway:

1. Should outputs be aligned in terms of process title, so should we
aim with this $patch to also include the full process name (like
`postgres: postgres postgres [local]` above and often the operation
`CREATE TABLE` too) which seems to be coming from setproctitle(3bsd)
and does depend on update_process_title GUC. However on win32 this is
off (so nobody will touch it), because docs say 'This setting defaults
to on on most platforms, but it defaults to off on Windows due to that
platform's larger overhead for updating the process title'. IMHO it is
good as it is, which is to have something rather than nothing.
Personally for me it is pretty strange that original
backtrace_symbols(3) includes './progname' in the output on Linux, but
it is what we have today.

2. Code review itself:

a. nitpicking nearby:
+ * - Unix/Linux/: Uses backtrace() and backtrace_symbols() <--
git diff shows there's unnecessary empty space at the end

>  Confirmed no crashes or memory leaks

b. Shouldn't we call SymCleanup(process) at some point to free
resources anyway? (I'm wondering about the scenario in case a very
long-lived process hits $backtrace_functions every couple of seconds -
wouldn't that cause a leak over a very long term without SymCleanup()
?)

-J.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Import Statistics in postgres_fdw before resorting to sampling.
Next
From: Michael Paquier
Date:
Subject: Re: Use CompactAttribute more often, when possible