On Feb 9 2026, at 12:17 pm, Álvaro Herrera <[email protected]> wrote:
> On 2025-Nov-01, Bryan Green wrote: > Hey Bryan, Thanks for working on this. I'm not a "Windows person" but I keep a build-farm animal (unicorn - Win11/ARM64/MSVC) running, or at least I try. :) I saw this patch and felt it was a good idea, so I took a look at it applied what Álvaro just sent out to my working tree on unicorn. I'm fighting a few fires with it so having better diagnostic information might help. >> Done. Now the code prints symbol+offset+address first, then conditionally >> appends line info if both SymGetLineFromAddrW64 succeeds and the filename >> conversion succeeds. This eliminates the duplication. > > Thanks! > > I was a bit surprised that you were doing elog(WARNING) for some > problematic conditions when trying to write the backtrace. I think that > would work fine, because our elog.c stuff is all supposed to be > reentrant ... yet I think it's going to be odd (assuming it ever > happens). I think we should instead just print the diagnostics message > to the backtrace string, where it will be displayed together with the > main error being processed, in the place where the backtrace would be. Hey Álvaro, I agree with this. Good catch. > This applies particularly when SymFromAddrW() fails: instead of printing > the elog(WARNING) in a separate error entry, we would still print the > function address in the correct spot of the backtrace with a small > diagnostics about the symbol not being found. ... I think. > > What do *you* think? > > I also made the backtrace_cleanup() function exist always, but on > non-win32 builds it's unused, so I tagged it as such. > > Github is down at the moment, so I don't know if this actually compiles. > > 0001 is your patch (I may have pgindented it, not sure), 0002 are my > changes. > > -- > Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ I'm running tests again now, I'll let you know if the patch helped me to identify the issue I'm having. best. -greg
