Re: repack: fix uninitialized DecodingWorkerShared.initialized

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: repack: fix uninitialized DecodingWorkerShared.initialized
Date: 2026-04-17 10:27:19
Message-ID: CA+hUKG+YxHMjaSzhgsXd9stiAiaQCjsM9Q2u+_emCBrN_iqvdg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 16, 2026 at 2:17 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> I checked the code of dsm_create(), and I did not see anything showing that the created shared-memory segment is zeroed.
>
> This is actually just an eyeball finding. From my tracing on my MacBook, after shared = (DecodingWorkerShared *) dsm_segment_address(seg);, the memory 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).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2026-04-17 10:35:17 Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value)
Previous Message Tatsuo Ishii 2026-04-17 10:13:03 Re: Row pattern recognition