On Sat, Jul 08, 2023 at 04:44:06PM -0400, Joseph Koshakow wrote: > 2023-07-08 16:33:27.787 EDT [157141] PANIC: ERRORDATA_STACK_SIZE exceeded > 2023-07-08 16:33:27.882 EDT [156878] LOG: server process (PID 157141) was > terminated by signal 6: Aborted > 2023-07-08 16:33:27.882 EDT [156878] DETAIL: Failed process was running: > CREATE TABLE t (); > > I think the issue here is that if a session loses the ability to set > their session authorization in the middle of a transaction, then > rolling back the transaction may fail and cause the server to panic. > That's probably what the deleted comment mean when it said: > >> * It's OK because the check does not require catalog access and can't >> * fail during an end-of-transaction GUC reversion
Yeah. IIUC the ERROR longjmps to a block that calls AbortTransaction(), which ERRORs again when resetting the session authorization, which causes us to call AbortTransaction() again, etc., etc. > Interestingly, if the r1 session manually types `ROLLBACK` instead of > executing a command that fails, then everything is fine and there's no > panic. I'm not familiar enough with transaction handling to know why > there would be a difference there. I haven't had a chance to dig into this one yet, but that is indeed interesting. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com