Hi, On 2021-05-06 21:43:32 -0400, Tom Lane wrote: > 2. We evidently need to put a bit more effort into this error > reporting logic. More generally, I wonder how we could audit > the code for similar hazards elsewhere, because I bet there are > some. (Or ... could it be sane to run functions included in > the ereport's arguments in ErrorContext?)
I have wondered about that before myself. It's pretty awkward to solve these kind of things at the caller level, and we have a perfectly good context to do this in, that we know is going to be reset. However - we don't reset ErrorContext for DEBUG messages, I believe. So there'd be a noticeable increase in leaking into ErrorContext, unless we change how we do that? I guess I could see only switching to another memory context for >= ERROR, but it does seem a bit odd. But for PANIC etc it's quite annoying to loose the actual error message on the buildfarm. > > Unfortunately there is no libbacktrace in that release, and for some > > reason we don't see a core being analysed... (gdb not installed, > > looking for wrong core file pattern, ...?) > > That I'm not sure about. gdb is certainly installed, and thorntail is > visibly running the current buildfarm client and is configured with the > correct core_file_glob, and I can report that the crash did leave a 'core' > file in the data directory (so it's not a case of systemd commandeering > the core dump). Seems like core-file collection should've worked > ... unless maybe it's not covering TAP tests at all? I suspect that is it - there's not really a good way for the buildfarm client to even know where there could be data directories :(. Greetings, Andres Freund
