| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Bryan Green <dbryan(dot)green(at)gmail(dot)com> |
| Cc: | Euler Taveira <euler(at)eulerto(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Add Windows support for backtrace_functions (MSVC only) |
| Date: | 2026-02-23 22:07:47 |
| Message-ID: | 202602232201.2d5ez5tbrkg2@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexandre Felipe | 2026-02-23 22:08:29 | Re: New access method for b-tree. |
| Previous Message | Bryan Green | 2026-02-23 21:40:57 | Re: [PATCH] Add Windows support for backtrace_functions (MSVC only) |