On Tue, Apr 7, 2026 at 2:59 PM Antonin Houska <[email protected]> wrote:
> Antonin Houska <[email protected]> wrote: > > > Srinath Reddy Sadipiralla <[email protected]> wrote: > > > > > i looked into this , it seems like valgrind catches the uninitialised > padding bytes, which > > > repack worker is writing using BufFileWrite, it seems this fix solved > the problem. > > > > > > diff --git a/src/backend/utils/time/snapmgr.c > b/src/backend/utils/time/snapmgr.c > > > index 2e6197f5f35..f5682b87626 100644 > > > --- a/src/backend/utils/time/snapmgr.c > > > +++ b/src/backend/utils/time/snapmgr.c > > > @@ -1739,6 +1739,8 @@ SerializeSnapshot(Snapshot snapshot, char > *start_address) > > > > > > Assert(snapshot->subxcnt >= 0); > > > > > > + MemSet(&serialized_snapshot, 0, sizeof(SerializedSnapshotData)); > > > + > > > /* Copy all required fields */ > > > serialized_snapshot.xmin = snapshot->xmin; > > > serialized_snapshot.xmax = snapshot->xmax; > > > > > > thoughts? > > > > Could you reproduce the failure in your environment? > > > > I haven't thought of this explanation because BufFileWrite() only copies > the > > data to a buffer in the BufFile structure and BufFileDumpBuffer() writes > the > > buffer. Maybe valgrind is able to track the copying? > > Given this message, you may be right: > > ==1617044== Address 0x12d745e2 is 106 bytes inside a block of size 8,272 > client-defined > > In my environment, the 'buffer' field starts at offset 80 into the BufFile > structure. We first write 8 bytes into it > > BufFileWrite(file, &snap_size, sizeof(snap_size)); > > followed by the snapshot. Since sizeof(SerializedSnapshotData) is 24, the > offset 106 should be the padding following the 'takenDuringRecovery' field. > yeah , same in my environment aslo ==00:00:00:06.569 3479320== Syscall param pwrite64(buf) points to uninitialised byte(s) ==00:00:00:06.569 3479320== at 0x55D6D38: pwrite (pwrite64.c:25) ==00:00:00:06.569 3479320== by 0x842EE7: pg_pwritev (pg_iovec.h:101) ==00:00:00:06.569 3479320== by 0x845F67: FileWriteV (fd.c:2280) ==00:00:00:06.569 3479320== by 0x840877: FileWrite (fd.h:245) ==00:00:00:06.569 3479320== by 0x841407: BufFileDumpBuffer (buffile.c:538) ==00:00:00:06.569 3479320== by 0x841A67: BufFileFlush (buffile.c:724) ==00:00:00:06.569 3479320== by 0x8410B7: BufFileClose (buffile.c:418) ==00:00:00:06.569 3479320== by 0x4BFBBB: export_initial_snapshot (repack_worker.c:346) ==00:00:00:06.569 3479320== by 0x4BF703: RepackWorkerMain (repack_worker.c:145) ==00:00:00:06.569 3479320== by 0x765D3F: BackgroundWorkerMain (bgworker.c:865) ==00:00:00:06.569 3479320== by 0x76C703: postmaster_child_launch (launch_backend.c:265) ==00:00:00:06.569 3479320== by 0x774F87: StartBackgroundWorker (postmaster.c:4197) ==00:00:00:06.569 3479320== Address 0x7b055f2 is 106 bytes inside a block of size 8,272 client-defined ==00:00:00:06.569 3479320== at 0xB234F4: palloc (mcxt.c:1411) ==00:00:00:06.569 3479320== by 0x8408BF: makeBufFileCommon (buffile.c:121) ==00:00:00:06.569 3479320== by 0x840C2F: BufFileCreateFileSet (buffile.c:272) ==00:00:00:06.569 3479320== by 0x4BFB7F: export_initial_snapshot (repack_worker.c:341) ==00:00:00:06.569 3479320== by 0x4BF703: RepackWorkerMain (repack_worker.c:145) ==00:00:00:06.569 3479320== by 0x765D3F: BackgroundWorkerMain (bgworker.c:865) ==00:00:00:06.569 3479320== by 0x76C703: postmaster_child_launch (launch_backend.c:265) ==00:00:00:06.569 3479320== by 0x774F87: StartBackgroundWorker (postmaster.c:4197) ==00:00:00:06.569 3479320== by 0x775277: maybe_start_bgworkers (postmaster.c:4362) ==00:00:00:06.569 3479320== by 0x7739F7: LaunchMissingBackgroundProcesses (postmaster.c:3437) ==00:00:00:06.569 3479320== by 0x770C2B: ServerLoop (postmaster.c:1737) ==00:00:00:06.569 3479320== by 0x77037B: PostmasterMain (postmaster.c:1412) ==00:00:00:06.569 3479320== Uninitialised value was created by a stack allocation ==00:00:00:06.569 3479320== at 0xB43008: SerializeSnapshot (snapmgr.c:1737) ==00:00:00:06.569 3479320== and you are spot on here with the explanation with offsets Size snap_size; 8 bytes; TransactionId xmin; 4 bytes TransactionId xmax; 4 bytes uint32 xcnt; 4 bytes int32 subxcnt; 4 bytes bool suboverflowed; 1 byte bool takenDuringRecovery; 1 byte /* 2 bytes of padding */ CommandId curcid; 4 bytes -- Thanks, Srinath Reddy Sadipiralla EDB: https://www.enterprisedb.com/
