| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] pg_surgery: check the page header and line pointers |
| Date: | 2026-09-08 00:02:44 |
| Message-ID: | CAGRkXqSfh__Ny-sHCWbKq0O46eRetXJtM+fYNEY_OOZ1V=07Cg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Nitin,
Thanks for the review, and good catch.
> Since both values can be
> misaligned on a build with 8-byte MAXALIGN, the condition may
> short-circuit at the alignment check without exercising the
> page-boundary checks. Would it make sense to use aligned values such
> as 32736 and 128,so that either bit-field interpretation reaches a
> boundary check?
You are right. With the old value, lp_off decodes as either 32767 or
100, and neither one is a multiple of 8. So on a build with 8-byte
MAXALIGN the code stops at the alignment check and never reaches the
pd_upper / pd_special checks. The test looked like it passed, but it
only covered one of the three branches.
v4 uses 32736 and 128 as you suggested. Both are MAXALIGNed and both
are at least as long as a heap tuple header, so the code always gets
as far as a page boundary check
I also make a few cosmetic changes for errcode and variable declaration.
Given we had 2 LGTM for this patch, I will mark it Ready For Committer
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-pg_surgery-skip-blocks-and-line-pointers-that-are.patch | application/octet-stream | 8.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-09-08 00:06:50 | Re: [DOC] pg_database_size/pg_tablespace_size error on a missing OID |
| Previous Message | Tom Lane | 2026-09-07 23:38:10 | Re: Introducing find_all_inheritors_ordered() |