Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wA2wB-0020vI-0x for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 09:41:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wA2w8-00GQ80-2V for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 09:41:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wA2w8-00GQ7p-1D for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 09:41:32 +0000 Received: from mail-vs1-xe2b.google.com ([2607:f8b0:4864:20::e2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wA2w6-000000010dE-2FtT for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 09:41:31 +0000 Received: by mail-vs1-xe2b.google.com with SMTP id ada2fe7eead31-6058a7dc4ebso1497855137.2 for ; Tue, 07 Apr 2026 02:41:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775554890; cv=none; d=google.com; s=arc-20240605; b=OFnfao1/cbrCYcTrDnpSZ24gcXOgfzl1kODwJKhYSO0KF9JPeWquYEleRVBjCn9LUY XUvWlOlXqN1zFOMLz3YsgGGg+7mZNotzBEot+Tiq97ZLN3U9NFG6ImRQrNod8f1XtgmU YUKMHZyeS8QkEwK8NECw504NVPtH7AKBgqQxgcvqw2ySsNOG84AwOPOnLTPSPigtf03b MmwLWm5kXGyGbkSBSjRFtQS0rmb/gXsJ0JqRt6JsROY1arOOn6Jis6nzdUSel9EK5NTH zBlk4goEYy65lLdfZpEBqW6AdysVVRhyKugGZX++s6U81NbkAatOXIaaMHjATiV2fvsA encA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=o+mJvfP8z3Wp6E4+laL5pZzmX5+UIyRtp8ytpxFbCnU=; fh=Ya9SrxzX+HNTYF2+m1iVjE2328fUrVKUwCIfVUN38ak=; b=R06ryEAXYdk7GHD+ev99UnK5ZNvGZEJiQlbtrFAwqvKWUZduMXPW6+h8hRxyJGtyOl kP5/XYRvd70MNtls1z4X1yrvDAf6q3Y6a8PAH9i4Ur3jDGplXTmNDhGF9tMfbxU15SGn Gdemit1BXCzb/Vba5Ip4lZ4dyg0GyJCRIJdWsF1IRDIovJbxok4e2BIwOj/GRnPl6fC8 NDdAMCecLottSl3+EHyWdxEF2oGtmpQ67NstVWT/gOTpIg6snpvs6l510n8bxziPkxIa ULZpcdTwQMokHmdnvT8pLcmmzNx5vw3SUEOIK6Bw9f0UtuVCfAs/8bavsUdhFGsmfeSe tvyQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775554890; x=1776159690; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=o+mJvfP8z3Wp6E4+laL5pZzmX5+UIyRtp8ytpxFbCnU=; b=fkSKi4aTZDUeufqYLlMFJDHHY6dhmIhSUm4In0ZTP28mztwJukQkJbHCn6WqUtitSV xxosNCen4Ab7Z7jaOkmyd2ayb2EeQQTay5ItDx2f5QrHn4nxu7UwJ+V79P2fLs0LxoiW bQlaIx7O77HnndvuhKutiewUXZFJrXXpGg84gPuJH4ys+wSvDk6dqlzijmptouNcianP iU+iN4kh0DBfHLemtuVKq2yCU3ZYWgMxZRceZd0POwSYjA4ujnSPD8G698/gCOWLKA4o sfXGevdos8e6GyhjMq9S8ris/MbkgQB7YU+i79J/OmPjLLd6jHL2vNnebwAkDdsr2X1X Nv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775554890; x=1776159690; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=o+mJvfP8z3Wp6E4+laL5pZzmX5+UIyRtp8ytpxFbCnU=; b=Jdvft3S/4DbWa4e44xipfv1NIuoUC6sO2rj2FSJ8pH2gMmagnLI0F8OU9Yo7dTxUb8 48zLypRhjx38DDueU3piXNpoPwclwk38sBQHkn8hYkR1ySIeAZot66Zgy/98frCtfRfO hzFmGdAejL/Bo2aY7OFHPibeSYoA5OanQ1u1Rt0yYLmIsgkcI+f0Zm5JYvT5kqHfz1ui 8rt0XHl6ers4w/ssMk14+WeZoK+KX/iRNn7QbB5Ppo9NqwgkTlHUiJDjgFKZZANMhiaD nuKDEx9hWF/Q+kDwnlL4XZcXb8qHUg3qivkHdC2KpFhhACYW+qqCfzrWr/L54gecbrEt AzKQ== X-Forwarded-Encrypted: i=1; AJvYcCW6Ce8x4p84/z1E7+E/ZddIsUt5xbuuWG2TWp87sju1uAOmu8eXevLBOg9uKfkJpu0ODIWQWDXv/Yv+ycxv@lists.postgresql.org X-Gm-Message-State: AOJu0YzVHu+EUVatlOZo9qgVw5n8pd7bVXoKmBD9iTqQwHj1JP4Uxq94 cqtR+TqOZ5s89FDSIfyoLuMMFiJUNsPetoqzHR4Mc65jgcLg44Of9RBA+tedsEMxgHouWo94vyO FNZ2bx4f4qwAyqO51m3utTdVMPFdo0wc= X-Gm-Gg: AeBDietTvwMyXcognd0arkB3maVasroqQo9s+kA72Vf1wvVrBWqcXwEC3Q6DnSoZvdG CngQubzX51PBSIDgvHzWzk7emZKmGRD9/aA43pk0C+pScA1Dh6rI3uo39OktCjFHSqIti0vCRcr CNhkUrc/4lczUCpi7pR7VqfG0Za3bPGfDrAMUdfOrwpmZCBHptSUJjrWkiSvVOXfxc/PMVkeamV qvVnpkSsmsxDA5uekaECJ0kJfbJ6RZhSu7Nu6kpQEXEKNNrgAhnAscVlyp51HjCl2U8cJ2FVxJ6 2A/xxGmhwJg9HFJR4XaBSoMSBlxTH16nMy+3q9gpcg5KXzw7BfxV+UTctiBhe+xWhebuMkjKmLL itj4Cf0HV4ZqkawO9iYdXnC6KDQ== X-Received: by 2002:a05:6102:47:b0:606:545:aaf0 with SMTP id ada2fe7eead31-6060545afbcmr186444137.27.1775554889689; Tue, 07 Apr 2026 02:41:29 -0700 (PDT) MIME-Version: 1.0 References: <202604060918.qw5ms7cbr2hz@alvherre.pgsql> <20260407011056.50.noahmisch@microsoft.com> <1976915.1775537087@sss.pgh.pa.us> <188275.1775552266@localhost> <192673.1775554157@localhost> In-Reply-To: <192673.1775554157@localhost> From: Srinath Reddy Sadipiralla Date: Tue, 7 Apr 2026 15:11:17 +0530 X-Gm-Features: AQROBzBkFplFGKW8qn9msMi_tAVblxbNeoPWX3dc17_ZTGAFJ8VcLprBp_6oHds Message-ID: Subject: Re: Adding REPACK [concurrently] To: Antonin Houska Cc: Tom Lane , Andres Freund , Noah Misch , Alvaro Herrera , vignesh C , Amit Kapila , Mihail Nikalayeu , Matthias van de Meent , Pg Hackers , Robert Treat Content-Type: multipart/alternative; boundary="0000000000007aae7c064edb9612" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007aae7c064edb9612 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 7, 2026 at 2:59=E2=80=AFPM Antonin Houska wrot= e: > Antonin Houska wrote: > > > Srinath Reddy Sadipiralla 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 >=3D 0); > > > > > > + MemSet(&serialized_snapshot, 0, sizeof(SerializedSnapshotData)); > > > + > > > /* Copy all required fields */ > > > serialized_snapshot.xmin =3D snapshot->xmin; > > > serialized_snapshot.xmax =3D snapshot->xmax; > > > > > > thoughts? > > > > Could you reproduce the failure in your environment? > > > > I haven't thought of this explanation because BufFileWrite() only copie= s > the > > data to a buffer in the BufFile structure and BufFileDumpBuffer() write= s > the > > buffer. Maybe valgrind is able to track the copying? > > Given this message, you may be right: > > =3D=3D1617044=3D=3D Address 0x12d745e2 is 106 bytes inside a block of si= ze 8,272 > client-defined > > In my environment, the 'buffer' field starts at offset 80 into the BufFil= e > 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' fiel= d. > yeah , same in my environment aslo =3D=3D00:00:00:06.569 3479320=3D=3D Syscall param pwrite64(buf) points to uninitialised byte(s) =3D=3D00:00:00:06.569 3479320=3D=3D at 0x55D6D38: pwrite (pwrite64.c:25) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x842EE7: pg_pwritev (pg_iovec.h:= 101) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x845F67: FileWriteV (fd.c:2280) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x840877: FileWrite (fd.h:245) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x841407: BufFileDumpBuffer (buffile.c:538) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x841A67: BufFileFlush (buffile.c= :724) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x8410B7: BufFileClose (buffile.c= :418) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x4BFBBB: export_initial_snapshot (repack_worker.c:346) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x4BF703: RepackWorkerMain (repack_worker.c:145) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x765D3F: BackgroundWorkerMain (bgworker.c:865) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x76C703: postmaster_child_launch (launch_backend.c:265) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x774F87: StartBackgroundWorker (postmaster.c:4197) =3D=3D00:00:00:06.569 3479320=3D=3D Address 0x7b055f2 is 106 bytes inside = a block of size 8,272 client-defined =3D=3D00:00:00:06.569 3479320=3D=3D at 0xB234F4: palloc (mcxt.c:1411) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x8408BF: makeBufFileCommon (buffile.c:121) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x840C2F: BufFileCreateFileSet (buffile.c:272) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x4BFB7F: export_initial_snapshot (repack_worker.c:341) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x4BF703: RepackWorkerMain (repack_worker.c:145) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x765D3F: BackgroundWorkerMain (bgworker.c:865) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x76C703: postmaster_child_launch (launch_backend.c:265) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x774F87: StartBackgroundWorker (postmaster.c:4197) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x775277: maybe_start_bgworkers (postmaster.c:4362) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x7739F7: LaunchMissingBackgroundProcesses (postmaster.c:3437) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x770C2B: ServerLoop (postmaster.= c:1737) =3D=3D00:00:00:06.569 3479320=3D=3D by 0x77037B: PostmasterMain (postmaster.c:1412) =3D=3D00:00:00:06.569 3479320=3D=3D Uninitialised value was created by a s= tack allocation =3D=3D00:00:00:06.569 3479320=3D=3D at 0xB43008: SerializeSnapshot (snapmgr.c:1737) =3D=3D00:00:00:06.569 3479320=3D=3D 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 --=20 Thanks, Srinath Reddy Sadipiralla EDB: https://www.enterprisedb.com/ --0000000000007aae7c064edb9612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 7, = 2026 at 2:59=E2=80=AFPM Antonin Houska <ah@cybertec.at> wrote:
Antonin Houska <ah@cybertec.at> wrote:

> Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:
>
> > i looked into this , it seems like valgrind catches the uninitial= ised padding bytes, which
> > repack worker is writing using BufFileWrite, it seems this fix so= lved 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)
> >=C2=A0
> >=C2=A0 =C2=A0Assert(snapshot->subxcnt >=3D 0);
> >=C2=A0
> > + MemSet(&serialized_snapshot, 0, sizeof(SerializedSnapshotDa= ta));
> > +
> >=C2=A0 =C2=A0/* Copy all required fields */
> >=C2=A0 =C2=A0serialized_snapshot.xmin =3D snapshot->xmin;
> >=C2=A0 =C2=A0serialized_snapshot.xmax =3D 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() writ= es the
> buffer. Maybe valgrind is able to track the copying?

Given this message, you may be right:

=3D=3D1617044=3D=3D=C2=A0 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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 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=C2=A0<= br>
=3D=3D00:00:00:06.569 3479320=3D=3D Syscall param pwrite64(buf) poin= ts to uninitialised byte(s)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 = =C2=A0at 0x55D6D38: pwrite (pwrite64.c:25)
=3D=3D00:00:00:06.569 3479320= =3D=3D =C2=A0 =C2=A0by 0x842EE7: pg_pwritev (pg_iovec.h:101)
=3D=3D00:00= :00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x845F67: FileWriteV (fd.c:2280)=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x840877: FileWrite (= fd.h:245)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x841407: = BufFileDumpBuffer (buffile.c:538)
=3D=3D00:00:00:06.569 3479320=3D=3D = =C2=A0 =C2=A0by 0x841A67: BufFileFlush (buffile.c:724)
=3D=3D00:00:00:06= .569 3479320=3D=3D =C2=A0 =C2=A0by 0x8410B7: BufFileClose (buffile.c:418)=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x4BFBBB: export_init= ial_snapshot (repack_worker.c:346)
=3D=3D00:00:00:06.569 3479320=3D=3D = =C2=A0 =C2=A0by 0x4BF703: RepackWorkerMain (repack_worker.c:145)
=3D=3D0= 0:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x765D3F: BackgroundWorkerMain= (bgworker.c:865)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x= 76C703: postmaster_child_launch (launch_backend.c:265)
=3D=3D00:00:00:06= .569 3479320=3D=3D =C2=A0 =C2=A0by 0x774F87: StartBackgroundWorker (postmas= ter.c:4197)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0Address 0x7b055f2 = is 106 bytes inside a block of size 8,272 client-defined
=3D=3D00:00:00:= 06.569 3479320=3D=3D =C2=A0 =C2=A0at 0xB234F4: palloc (mcxt.c:1411)
=3D= =3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x8408BF: makeBufFileCommo= n (buffile.c:121)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x= 840C2F: BufFileCreateFileSet (buffile.c:272)
=3D=3D00:00:00:06.569 34793= 20=3D=3D =C2=A0 =C2=A0by 0x4BFB7F: export_initial_snapshot (repack_worker.c= :341)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x4BF703: Repa= ckWorkerMain (repack_worker.c:145)
=3D=3D00:00:00:06.569 3479320=3D=3D = =C2=A0 =C2=A0by 0x765D3F: BackgroundWorkerMain (bgworker.c:865)
=3D=3D00= :00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x76C703: postmaster_child_laun= ch (launch_backend.c:265)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2= =A0by 0x774F87: StartBackgroundWorker (postmaster.c:4197)
=3D=3D00:00:00= :06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x775277: maybe_start_bgworkers (post= master.c:4362)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x773= 9F7: LaunchMissingBackgroundProcesses (postmaster.c:3437)
=3D=3D00:00:00= :06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x770C2B: ServerLoop (postmaster.c:17= 37)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0 =C2=A0by 0x77037B: Postma= sterMain (postmaster.c:1412)
=3D=3D00:00:00:06.569 3479320=3D=3D =C2=A0U= ninitialised value was created by a stack allocation
=3D=3D00:00:00:06.5= 69 3479320=3D=3D =C2=A0 =C2=A0at 0xB43008: SerializeSnapshot (snapmgr.c:173= 7)
=3D=3D00:00:00:06.569 3479320=3D=3D

and you are spot on here w= ith the explanation with offsets

Size snap_size; 8 bytes;
Trans= actionId 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 cur= cid; 4 bytes
=C2=A0

--
Thanks,
Srinath Reddy Sadi= piralla
EDB:=C2=A0https://www.enterprisedb.com/
--0000000000007aae7c064edb9612--