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

From Bryan Green
Subject Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
Date
Msg-id 0f76b00a-8d8d-4c6f-ba41-bf6ec5fb08e1@gmail.com
Whole thread Raw
In response to Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
List pgsql-hackers
On 2/23/2026 4:07 PM, Álvaro Herrera wrote:
> On 2026-Feb-23, Bryan Green wrote:
> 
>> I have implemented DuplicateHandle and closed the handle in the
>> appropriate places.  I also reset backtrace_process to NULL if
>> SymInitialize() fails.  Patch is attached.
> 
> Hmm, should then backtrace_cleanup() cope with the case where it's NULL?
> 
> Also, I wonder what happens if one "backtraceable" error occurs, and we
> fail to SymInitialize(), then another backtraceable error occurs.
> Should we do the DuplicateHandle()+SymInitialize() dance again, or
> should we just give up?  The current implementation does the former, I
> think; but the latter is also easily achievable by setting
> backtrace_symbols_initialized to true and leaving backtrace_process as
> NULL; then this case can be detected specifically in set_backtrace() and
> treated as a case where we just return NULL before attempting anything
> else.
> 
I have removed all but the SymCleanup form the backtrace_cleanup since
it happens at process exit.  I have implemented not retrying as you
described above.

Let me know if this was what you were thinking.

Patch attached.

-- 
Bryan Green
EDB: https://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Modernize error message for malformed B-Tree tuple posting
Next
From: Henson Choi
Date:
Subject: Re: Row pattern recognition