On Sat, Aug 12, 2023 at 12:56 AM Andres Freund <and...@anarazel.de> wrote: > On 2023-08-11 11:56:27 -0700, Peter Geoghegan wrote: > > On Fri, Aug 11, 2023 at 11:23 AM Andres Freund <and...@anarazel.de> wrote: > > > > Couldn't you say the same thing about defensive "can't happen" ERRORs? > > > > They are essentially a form of assertion that isn't limited to > > > > assert-enabled builds. > > > > > > Yes. A lot of them I hate them with the passion of a thousand suns ;). > > > "Oh, > > > our transaction state machinery is confused. Yes, let's just continue > > > going > > > through the same machinery again, that'll resolve it.". > > > > I am not unsympathetic to Ashutosh's point about conventional ERRORs > > being easier to deal with when debugging your own code, during initial > > development work. > > Oh, I am as well - I just don't think it's a good idea to introduce "log + > error" > assertions to core postgres, because it seems very likely that they'll end up > getting used a lot. > >
I am open to ideas which allow the same backend to recover after meeting an easily recoverable but "can't happen" condition rather than losing that backend and starting all over with a new backend. Not all Assert'ed conditions are recoverable so a blanket GUC or compile time option won't help. Those might make things worse. We need two separate incantations for non-recoverable and recoverable Asserts respectively. I like Peter's idea of having a new elevel, however it still requires adding conditional USE_ASSERT, an if testing the condition and then writing an error message. AssertLog() in the patch uses just a few more letters. It won't help to expand the scope of the problem since that will reduce the chances of getting anything done. -- Best Wishes, Ashutosh Bapat
