Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: repack: fix uninitialized DecodingWorkerShared.initialized
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <26785.1776265652@localhost>
Date: Fri, 17 Apr 2026 11:41:37 +0800
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3564E6C-CF19-4770-A89B-00FCF0A647D1@gmail.com>
References: <9AFE5694-9420-40C3-842C-4A4473E1D02B@gmail.com>
 <26785.1776265652@localhost>
To: Antonin Houska <ah@cybertec.at>
Archived-At: 
 <https://www.postgresql.org/message-id/A3564E6C-CF19-4770-A89B-00FCF0A647D1%40gmail.com>
Precedence: bulk


> On Apr 15, 2026, at 23:07, Antonin Houska <ah@cybertec.at> wrote:
>=20
> Chao Li <li.evan.chao@gmail.com> wrote:
>=20
>> I have not reviewed the repack-related patches before. Recently, I =
started trying to understand how repack works and trace through the =
code.
>=20
> Thanks, I appreciate that!
>=20
>> While tracing start_repack_decoding_worker(), I noticed something =
suspicious:
>>=20
>> ```
>> seg =3D dsm_create(size, 0);
>> shared =3D (DecodingWorkerShared *) dsm_segment_address(seg);
>> shared->lsn_upto =3D InvalidXLogRecPtr;
>> shared->done =3D false;
>> SharedFileSetInit(&shared->sfs, seg);
>> shared->last_exported =3D -1;
>> SpinLockInit(&shared->mutex);
>> shared->dbid =3D MyDatabaseId;
>> ```
>>=20
>> Here, the code creates a shared-memory segment and lets =E2=80=9Cshared=
" point to that memory. It then initializes some fields of =E2=80=9Cshared=
". However, later code reads shared->initialized, but this field was not =
initialized:
>=20
> The problem was noticed earlier this week and I already posted a fix =
[1].
>=20
>> For the fix, since start_repack_decoding_worker() is not on a hot =
path, I think it is fine to zero the whole shared struct explicitly, and =
then initialize the non-zero fields afterwards.
>=20
> Although not strongly, I prefer setting individual fields explicitly.
>=20
>=20
> [1] =
https://www.postgresql.org/message-id/182883.1776073323%40localhost
>=20
> --=20
> Antonin Houska
> Web: https://www.cybertec-postgresql.com

I saw 05c401d5786a05ea630e884ffa492aa01683d15b has fixed this issue, so =
this patch is no longer needed.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/