07.03.2023 09:00, Alexander Lakhin wrote:
> I've tried to materialize newslot before the oldslot materialization
> (in ExecFetchSlotHeapTuple(), where their common memory is released),
> and it looks like it fixes the issue.
I've made a simple isolation test to illustrate the bug, which I'd consider
as serious. On master it shows (under valgrind):
# using temp instance on port 61696 with PID 614130
not ok 1 - bru-trigger 2147 ms
# (test process exited with exit code 1)
src/test/isolation/output_iso/log/postmaster.log contains:
...
==00:00:00:05.840 615284== Invalid read of size 1
==00:00:00:05.840 615284== at 0x1E376C: heap_compute_data_size (heaptuple.c:147)
==00:00:00:05.840 615284== by 0x1E4458: heap_form_tuple (heaptuple.c:1061)
==00:00:00:05.840 615284== by 0x3DB74A: tts_buffer_heap_materialize (execTuples.c:749)
==00:00:00:05.840 615284== by 0x3DC5EB: ExecFetchSlotHeapTuple (execTuples.c:1655)
==00:00:00:05.840 615284== by 0x3A6BA7: ExecBRUpdateTriggers (trigger.c:3032)
==00:00:00:05.840 615284== by 0x3FE207: ExecUpdatePrologue (nodeModifyTable.c:1916)
==00:00:00:05.840 615284== by 0x3FF838: ExecUpdate (nodeModifyTable.c:2289)
==00:00:00:05.840 615284== by 0x401BD4: ExecModifyTable (nodeModifyTable.c:3795)
==00:00:00:05.840 615284== by 0x3D65FF: ExecProcNodeFirst (execProcnode.c:464)
==00:00:00:05.840 615284== by 0x3CE4F5: ExecProcNode (executor.h:272)
==00:00:00:05.840 615284== by 0x3CE585: ExecutePlan (execMain.c:1633)
==00:00:00:05.840 615284== by 0x3CF220: standard_ExecutorRun (execMain.c:364)
...
2023-04-01 14:26:31.543 MSK postmaster[615243] LOG: server process (PID 615284) exited with exit code 1
2023-04-01 14:26:31.543 MSK postmaster[615243] DETAIL: Failed process was running: UPDATE bruttest SET cnt = cnt + 1;
Maybe the test could supplement a fix (I'm still unsure how to fix the issue
right way).
Best regards,
Alexander
