Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
От | Michael Paquier |
---|---|
Тема | Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution |
Дата | |
Msg-id | aHbt_HkrM3TTH61j@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
|
Список | pgsql-bugs |
On Tue, Jul 15, 2025 at 02:13:53PM -0400, Tom Lane wrote: > PG Bug reporting form <noreply@postgresql.org> writes: > > During testing a flow in an app, I encountered a segfault that only happens > > during parallel execution: > > https://gist.github.com/joy4eg/708458e204f52129a8e54a13534586b7 > > This report isn't terribly helpful, since you have not explained > how to trigger the crash. If we can't duplicate it, it's hard > to decide what is the appropriate fix. For the sake of visibility if the information on github gets lost, the change can be summarized by this query pattern, but we don't have any information about the end of the query: WITH replaced AS ( DELETE FROM replaceable_events_before_update WHERE replaced_by_id = ANY($1) RETURNING attr_list_1, [...] ), source_data (attr_list_2) AS ( SELECT * from replaced UNION ALL VALUES (attr_list_3 ... That's most likely generated a MERGE by an ORM to have these many parameters and columns listed. Without the full pattern or an idea of the schema as this includes triggers, what we can do is limited, as Tom says. And the relevant portion of the backtrace: #7 ExecGetUpdateNewTuple (oldSlot=0x55b0842d0288, #planSlot=0x55b084249d68, relinfo=0x55b0836a9b88) at #executor/./build/../src/backend/executor/nodeModifyTable.c:752 #8 ExecBRUpdateTriggers (estate=0x55b08369a708, #epqstate=0x55b0836a9a68, relinfo=0x55b0836a9b88, #tupleid=0x7fffc373628a, fdw_trigtuple=0x0, newslot=0x55b083720eb0, #tmresult=0x7fffc37361d0, tmfd=0x7fffc37362e0) at #commands/./build/../src/backend/commands/trigger.c:2979 #9 0x000055b08158628e in ExecUpdatePrologue #(context=context@entry=0x7fffc37362c0, #resultRelInfo=resultRelInfo@entry=0x55b0836a9b88, #tupleid=tupleid@entry=0x7fffc373628a, oldtuple=oldtuple@entry=0x0, #slot=slot@entry=0x55b083720eb0, result=result@entry=0x7fffc37361d0) #at executor/./build/../src/backend/executor/nodeModifyTable.c:1949 #10 0x000055b081587e75 in ExecMergeMatched (context=<optimized out>, #resultRelInfo=<optimized out>, tupleid=0x7fffc373628a, oldtuple=0x0, #canSetTag=false, matched=0x7fffc3736290) at #executor/./build/../src/backend/executor/nodeModifyTable.c:3023 If you could extract the query string from the backtrace, that would be one piece of information. With triggers and MERGE in mind, it may be possible to reproduce something. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: