Re: Stack overflow issue
От | Heikki Linnakangas |
---|---|
Тема | Re: Stack overflow issue |
Дата | |
Msg-id | 04c785f6-36ac-4065-8d29-9e4d66bfb5ad@iki.fi обсуждение исходный текст |
Ответ на | Re: Stack overflow issue (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Stack overflow issue
|
Список | 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)
Вложения
В списке pgsql-hackers по дате отправления: