MIME-Version: 1.0
References: <9AFE5694-9420-40C3-842C-4A4473E1D02B@gmail.com>
In-Reply-To: <9AFE5694-9420-40C3-842C-4A4473E1D02B@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Fri, 17 Apr 2026 22:27:19 +1200
Message-ID: 
 <CA+hUKG+YxHMjaSzhgsXd9stiAiaQCjsM9Q2u+_emCBrN_iqvdg@mail.gmail.com>
Subject: Re: repack: fix uninitialized DecodingWorkerShared.initialized
To: Chao Li <li.evan.chao@gmail.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKG%2BYxHMjaSzhgsXd9stiAiaQCjsM9Q2u%2B_emCBrN_iqvdg%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 16, 2026 at 2:17=E2=80=AFAM Chao Li <li.evan.chao@gmail.com> wr=
ote:
> I checked the code of dsm_create(), and I did not see anything showing th=
at the created shared-memory segment is zeroed.
>
> This is actually just an eyeball finding. From my tracing on my MacBook, =
after shared =3D (DecodingWorkerShared *) dsm_segment_address(seg);, the me=
mory always seemed to be zeroed, so I may have missed something. But given =
that the code explicitly initializes several other fields, it seems better =
not to rely on that implicitly.

For the record, that depends on whether you get a newly allocated
shared memory segment from the operating system, or recycled shared
memory reserved at startup with the min_dynamic_shared_memory setting
(as shown in Alexander Lakhin's reproducer).