Re: Segmentation fault during update inside ExecBRUpdateTriggers
От | Thomas Munro |
---|---|
Тема | Re: Segmentation fault during update inside ExecBRUpdateTriggers |
Дата | |
Msg-id | CA+hUKGK8dbkY+NC9TSH5heeq5jUQEYMZ1pATVY+CPjWAiSV4TA@mail.gmail.com обсуждение исходный текст |
Ответ на | Segmentation fault during update inside ExecBRUpdateTriggers (Piotr Gabriel Kosinski <pg.kosinski@gmail.com>) |
Ответы |
Re: Segmentation fault during update inside ExecBRUpdateTriggers
|
Список | pgsql-bugs |
On Fri, Aug 16, 2019 at 9:55 AM Piotr Gabriel Kosinski <pg.kosinski@gmail.com> wrote: > Backtrace on Debian Buster: > > #0 0x000055c9e358b0c0 in ?? () > #1 0x000055c9e133d144 in ExecBRUpdateTriggers > (estate=estate@entry=0x55c9e3583190, > epqstate=epqstate@entry=0x55c9e35845c0, > relinfo=relinfo@entry=0x55c9e3583420, > tupleid=tupleid@entry=0x7fff0e1565da, > fdw_trigtuple=fdw_trigtuple@entry=0x0, slot=0x55c9e3589688) at > ./build/../src/backend/commands/trigger.c:3065 Hi, Right, this happens on REL_11_STABLE but not on master (which rewrote the relevant code quite a bit in the "slotification" project). It's a double free, here: for (i = 0; i < trigdesc->numtriggers; i++) { ... if (oldtuple != newtuple && oldtuple != slottuple) heap_freetuple(oldtuple); ... } if (trigtuple != fdw_trigtuple && trigtuple != newtuple) heap_freetuple(trigtuple); In a very quick test, the following change fixes the problem and passes regression tests, but I'm not sure if it's the right fix. - if (oldtuple != newtuple && oldtuple != slottuple) + if (oldtuple != newtuple && oldtuple != slottuple && oldtuple != trigtuple) -- Thomas Munro https://enterprisedb.com
В списке pgsql-bugs по дате отправления: