| From: | Tender Wang <tndrwang(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | [PATCH] Simplify trivial shmem size calculations |
| Date: | 2026-03-10 12:59:22 |
| Message-ID: | CAHewXNnzUoUg_eDjvCQzzJaXxwvZmQbxJ2=Qwefab7iAT73TAw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While learning how PostgreSQL implements streaming replication, I
noticed that WalRcvShmemSize() calculating the shared
memory sizes that use a multi-step add_size pattern for single,
fixed-size structures.
...
Size
WalRcvShmemSize(void)
{
Size size = 0;
size = add_size(size, sizeof(WalRcvData));
return size;
}
...
"return sizeof(WalRcvData);" is equal to the above code.
I searched the other modules to see how they perform the calculations.
For example,
...
Size
VarsupShmemSize(void)
{
return sizeof(TransamVariablesData);
}
...
And I also found another case:
Size
XLogRecoveryShmemSize(void)
{
Size size;
/* XLogRecoveryCtl */
size = sizeof(XLogRecoveryCtlData);
return size;
}
The above code does not need to define the local variable size;
directly returning sizeof(XLogRecoveryCtlData) seems simpler.
I searched for other XXXShmemSize() calls in CalculateShmemSize() and
simplified them where possible.
Please see the attached patch.
I realize this might be a matter of coding style preference rather
than a functional necessity.
Is it worth standardizing these cases, or should we stick with the
current boilerplate for consistency?
Any thoughts?
--
Thanks,
Tender Wang
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Simplify-shmem-size-calulations.patch | application/octet-stream | 2.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jet | 2026-03-10 13:09:52 | Re: Potential security risk associated with function call |
| Previous Message | vignesh C | 2026-03-10 12:49:34 | Re: Skipping schema changes in publication |