On Friday, October 30th, 2026 at 4:34 AM, David Steele <[email protected]> wrote:
> On 10/30/26 00:08, Michael Paquier 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. So the previous guess was > > really right. Candles work. > > Thank you, Greg! This is exactly the confirmation we needed. Hey David, happy to help. As I said to Michael, now I can write off that UltraSPARC 45 and the power it gobbles up on my taxes with proof that it is used for work. > I would encourage you to file a bug with gcc. I've found a few bugs and > the gcc folks are really easy to work with. Since you have a repro it > will be easy to produce the pre-processed output they want. Sure, I'll carve out some time to do that. > One bad thing -- even if they fix the bug, distros may choose not to > back patch it (so it may already be fixed). I had to maintain a patch > for a gcc bug on ppc64le for years before the affected distros EOL'd. > That bug limited where I could use const, which was pretty annoying. But that's the life of an open source developer, right? I signed up for it so I can't complain. Or if I do, you should ignore me. > >> 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? > > Apparently so -- the failure of the base backup cancel test showed that. > The buffer was never used and just the larger frame caused the problem. I agree. > > 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. > > palloc/pfree seems like the simpler solution. +1 > > 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. I don't believe in luck and magic when it > > comes to software programming. > I've attached a patch for be_lo_export(). Working around compiler bugs > is never fun but I'm not sure what choice we have. I've not reviewed the patch yet, but it is on my queue. > Regards, > -David best. -greg
