Message-ID: <043bf2c3-d39a-4592-be83-bf68eb1befcf@gmail.com>
Date: Mon, 23 Feb 2026 21:36:31 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
Cc: Euler Taveira <euler@eulerto.com>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>,
 Michael Paquier <michael@paquier.xyz>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <202602232201.2d5ez5tbrkg2@alvherre.pgsql>
Content-Language: en-US
From: Bryan Green <dbryan.green@gmail.com>
In-Reply-To: <202602232201.2d5ez5tbrkg2@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/043bf2c3-d39a-4592-be83-bf68eb1befcf%40gmail.com>
Precedence: bulk

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.
> 
backtrace_cleanup() only cleans up on process exit-- so, it is almost a
style choice.  If we are going to close the handle in cleanup we should
probably stay consistent and reset backtrace_process to null as well.

If SymInitialize() fails...I can not imagine it ever succeeding after
that.  It is an expensive call...a process generating errors shouldn't
be burning time retrying a failing system call on every error.

I agree with not retrying.  I'll put together another patch with those
changes.

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