Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
Дата
Msg-id CAEZATCWyYB2sA72V4urCDjfY0hoS8gOjRj+9aDOnHarOReUzOg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
Список pgsql-bugs
On Thu, 17 Jul 2025 at 06:45, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Jul 16, 2025 at 02:05:06PM +0100, Dean Rasheed wrote:
> > I decided to do this by adding an extra "is_merge_update" boolean
> > parameter, rather than passing the commandType because that looked
> > slightly neater. It was also necessary to update
> > ExecBRDeleteTriggers(), since otherwise a concurrent MERGE DELETE
> > could do the wrong thing (execute the wrong action, rather than
> > seg-faulting). That was picked up by an existing isolation test case
> > added by 9321c79, so no need for more tests.
>
> Looks sensible here, for the HEAD and v17 flavors.

Thanks for looking.

> > I haven't tested this against the OP's reproducer.
>
> Except waiting for the OP to actually test the fix, I'm not sure if
> there is much that we can do.

I'll push this in a day or so in any case, since it's clearly fixing
*an* issue, even if it doesn't entirely fix the OP's issue.

> Anyway, the stack that one gets with
> the isolation test is very close to what the OP has reported, so I'm
> ready to bet a coffee that you have been able to narrow this one down.

Yeah, that was my thinking too.

> I have also raised an issue to timescale to make them aware of the
> issue.  I have no idea if this is an issue for them, just acting as a
> reporter:
> https://github.com/timescale/timescaledb/issues/8392

Cool, thanks for doing that.

Regards,
Dean



В списке pgsql-bugs по дате отправления: