Re: Stack overflow issue - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Stack overflow issue
Date
Msg-id 04c785f6-36ac-4065-8d29-9e4d66bfb5ad@iki.fi
Whole thread Raw
In response to Re: Stack overflow issue  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Stack overflow issue
List pgsql-hackers
On 11/01/2024 19:37, Robert Haas wrote:
> On Wed, Jan 10, 2024 at 4:25 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> The problem with CommitTransactionCommand (or rather
>> AbortCurrentTransaction() which has the same problem)
>> and ShowTransactionStateRec is that they get called in a state where
>> aborting can lead to a panic. If you add a "check_stack_depth()" to them
>> and try to reproducer scripts that Egor posted, you still get a panic.
> 
> Hmm, that's unfortunate. I'm not sure what to do about that. But I'd
> still suggest looking for a goto-free approach.

Here's one goto-free attempt. It adds a local loop to where the 
recursion was, so that if you have a chain of subtransactions that need 
to be aborted in CommitTransactionCommand, they are aborted iteratively. 
The TBLOCK_SUBCOMMIT case already had such a loop.

I added a couple of comments in the patch marked with "REVIEWER NOTE", 
to explain why I changed some things. They are to be removed before 
committing.

I'm not sure if this is better than a goto. In fact, even if we commit 
this, I think I'd still prefer to replace the remaining recursive calls 
with a goto. Recursion feels a weird to me, when we're unwinding the 
states from the stack as we go.

Of course we could use a "for (;;) { ... continue }" construct around 
the whole function, instead of a goto, but I don't think that's better 
than a goto in this case.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: tablecmds.c/MergeAttributes() cleanup
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: [PATCH] New predefined role pg_manage_extensions