On Fri, Apr 2, 2021 at 12:09 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > The buildfarm points out that this fails under valgrind. > I easily reproduced it here: > > ==00:00:03:42.115 3410499== Syscall param epoll_wait(events) points to > unaddressable byte(s) > ==00:00:03:42.115 3410499== at 0x58E926B: epoll_wait (epoll_wait.c:30) > ==00:00:03:42.115 3410499== by 0x7FC903: WaitEventSetWaitBlock > (latch.c:1452) > ==00:00:03:42.115 3410499== by 0x7FC903: WaitEventSetWait (latch.c:1398) > ==00:00:03:42.115 3410499== by 0x6BF46C: ExecAppendAsyncEventWait > (nodeAppend.c:1025) > ==00:00:03:42.115 3410499== by 0x6BF667: ExecAppendAsyncGetNext > (nodeAppend.c:915) > ==00:00:03:42.115 3410499== by 0x6BF667: ExecAppend (nodeAppend.c:337) > ==00:00:03:42.115 3410499== by 0x6D49E4: ExecProcNode (executor.h:257) > ==00:00:03:42.115 3410499== by 0x6D49E4: ExecModifyTable > (nodeModifyTable.c:2222) > ==00:00:03:42.115 3410499== by 0x6A87F2: ExecProcNode (executor.h:257) > ==00:00:03:42.115 3410499== by 0x6A87F2: ExecutePlan (execMain.c:1531) > ==00:00:03:42.115 3410499== by 0x6A87F2: standard_ExecutorRun > (execMain.c:350) > ==00:00:03:42.115 3410499== by 0x82597F: ProcessQuery (pquery.c:160) > ==00:00:03:42.115 3410499== by 0x825BE9: PortalRunMulti (pquery.c:1267) > ==00:00:03:42.115 3410499== by 0x826826: PortalRun (pquery.c:779) > ==00:00:03:42.115 3410499== by 0x82291E: exec_simple_query > (postgres.c:1185) > ==00:00:03:42.115 3410499== by 0x823F3E: PostgresMain (postgres.c:4415) > ==00:00:03:42.115 3410499== by 0x79BAC1: BackendRun (postmaster.c:4483) > ==00:00:03:42.115 3410499== by 0x79BAC1: BackendStartup (postmaster.c:4205) > ==00:00:03:42.115 3410499== by 0x79BAC1: ServerLoop (postmaster.c:1737) > ==00:00:03:42.115 3410499== Address 0x10d10628 is 7,960 bytes inside a > recently re-allocated block of size 8,192 alloc'd > ==00:00:03:42.115 3410499== at 0x4C30F0B: malloc (vg_replace_malloc.c:307) > ==00:00:03:42.115 3410499== by 0x94F9EA: AllocSetAlloc (aset.c:919) > ==00:00:03:42.115 3410499== by 0x957BAF: MemoryContextAlloc (mcxt.c:809) > ==00:00:03:42.115 3410499== by 0x958CC0: MemoryContextStrdup (mcxt.c:1179) > ==00:00:03:42.115 3410499== by 0x516AE4: untransformRelOptions > (reloptions.c:1336) > ==00:00:03:42.115 3410499== by 0x6E6ADF: GetForeignTable (foreign.c:273) > ==00:00:03:42.115 3410499== by 0xF3BD470: postgresBeginForeignScan > (postgres_fdw.c:1479) > ==00:00:03:42.115 3410499== by 0x6C2E83: ExecInitForeignScan > (nodeForeignscan.c:236) > ==00:00:03:42.115 3410499== by 0x6AF893: ExecInitNode (execProcnode.c:283) > ==00:00:03:42.115 3410499== by 0x6C0007: ExecInitAppend (nodeAppend.c:232) > ==00:00:03:42.115 3410499== by 0x6AFA37: ExecInitNode (execProcnode.c:180) > ==00:00:03:42.115 3410499== by 0x6D533A: ExecInitModifyTable > (nodeModifyTable.c:2575)
The reason for this would be that epoll_wait() is called with maxevents exceeding the size of the input event array in the test case. To fix, I adjusted the parameters to call the caller function WaitEventSetWait() with in ExecAppendAsyncEventWait(). Patch attached. Best regards, Etsuro Fujita
fix-ExecAppendAsyncEventWait-2021-04-05.patch
Description: Binary data
