On Thursday, October 29th, 2026 at 7:08 PM, Michael Paquier <[email protected]> wrote:
> On Thu, Oct 29, 2026 at 06:11:39PM +0000, Burd, Greg wrote: > > Validation of c97931c16d on the same machine: with it applied, three > > runs each of both reproductions give the WARNING and ERROR and no > > crash, and t/010_pg_basebackup.pl passes all 168 tests with no > > backend crash in the server logs. With it reverted, the same TAP run > > logs the SIGSEGV. The test still reports PASS in that case because > > it only checks that pg_basebackup fails. > > Ah, thanks for the in-depth investigation. Hey Michael, sure thing. It's why I bought the UltraSPARC 45, oddly enough! > So the previous guess was really right. Yes, you have a talent for many things including guessing fixes to obscure issues. > Candles work. Indeed they do. :) > > I don't see a better fix on our side. A helper function with > > the array would also work, but palloc0() is simpler, and both rely on > > the same thing: no PG_TRY() frame larger than 4kB. In a core build > > on this machine, the only other function with a frame that large that > > calls sigsetjmp() is be_lo_export() (char buf[BUFSIZE]). Its code > > after sigsetjmp() reloads the constant, so it is fine today, but only > > by luck of register allocation. I haven't checked contrib or other > > GCC versions or as mentioned earlier against their bug system. > > Ugh. Even if the buffer itself is not used within the try/catch > block itself? I could test if you'd like. > Getting entirely rid of the TRY/CATCH would lead to a > much nicer result overall: we'd be able to keep the local buffer. Or > perhaps go to the simpler solution of a palloc/pfree? I cannot > believe that this extra allocation would matter for lo_export() calls. > > If you are proved to be right, it sounds to me that we ought to > fix and backpatch that as well, especially if there is nothing we can > do on the Postgres side. Better safe than sorry. Even if I submit a bug to GCC and they fix it there it will take time to get that shipped and you have people who rarely update, etc. etc. > I don't believe in luck and magic when it comes to software programming. Nope, just 1s and 0s. > Thoughts? > -- > Michael best. -greg
