repack: fix uninitialized DecodingWorkerShared.initialized

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: repack: fix uninitialized DecodingWorkerShared.initialized
Date: 2026-04-15 10:22:44
Message-ID: 9AFE5694-9420-40C3-842C-4A4473E1D02B@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I have not reviewed the repack-related patches before. Recently, I started trying to understand how repack works and trace through the code.

While tracing start_repack_decoding_worker(), I noticed something suspicious:

```
seg = dsm_create(size, 0);
shared = (DecodingWorkerShared *) dsm_segment_address(seg);
shared->lsn_upto = InvalidXLogRecPtr;
shared->done = false;
SharedFileSetInit(&shared->sfs, seg);
shared->last_exported = -1;
SpinLockInit(&shared->mutex);
shared->dbid = MyDatabaseId;
```

Here, the code creates a shared-memory segment and lets “shared" point to that memory. It then initializes some fields of “shared". However, later code reads shared->initialized, but this field was not initialized:
```
for (;;)
{
bool initialized;

SpinLockAcquire(&shared->mutex);
initialized = shared->initialized;
SpinLockRelease(&shared->mutex);

if (initialized)
break;

ConditionVariableSleep(&shared->cv, WAIT_EVENT_REPACK_WORKER_EXPORT);
}
```

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 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.

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

Attachment Content-Type Size
v1-0001-repack-zero-initialize-DecodingWorkerShared.patch application/octet-stream 1010 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tender Wang 2026-04-15 10:30:01 Re: pg_plan_advice
Previous Message shveta malik 2026-04-15 10:15:43 Re: Support EXCEPT for TABLES IN SCHEMA publications