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 по дате отправления: