Feedback-ID: ie3de48e3:Fastmail
Date: Mon, 23 Feb 2026 23:07:47 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Bryan Green <dbryan.green@gmail.com>
Cc: Euler Taveira <euler@eulerto.com>,
	Jakub Wartak <jakub.wartak@enterprisedb.com>,
 Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
Message-ID: <202602232201.2d5ez5tbrkg2@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6dea1cfa-1efd-41cb-8d1e-ad35d4304aa3@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202602232201.2d5ez5tbrkg2%40alvherre.pgsql>
Precedence: bulk

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.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/