| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: Hash index corruption and CLOG lookup errors from checkpoint races |
| Date: | 2026-11-04 07:30:24 |
| Message-ID: | CALDaNm2PsvXXOUZp2rY7gAoHeACZh3bgd6o5EFUOamUASbA98Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 3 Nov 2026 at 09:38, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Vignesh,
>
> Thanks for catching this, and for the test. It fails on v1 as you
> describe.
>
> v2 drops the flag. _hash_alloc_buckets() now extends the file before
> writing the WAL record, so a checkpoint either replays the record or
> syncs the new block.
>
> ^^^^ is aligned with current heap extend behavior. Another way is to
> use PG_TRY and FINALLY to reset the flag. I prefer to use
> same mechanism because it is easy to understand in the future.
>
> 0001 and 0002 are unchanged.
The issue reported at [1] has not yet been fixed right? Just checking
to confirm it is not lost in the discussion.
[1] - https://www.postgresql.org/message-id/CALDaNm1%2BSiZ9SGt%3DX9KpOAx4vG8ZjrsXSq1o4nEiP7C_%3DNDGnA%40mail.gmail.com
Regards,
Vignesh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-11-04 07:32:10 | Re: Fix cumulative WAL statistics double-counting from parallel workers |
| Previous Message | Amit Langote | 2026-11-04 07:24:58 | Re: multi-row INSERT broken with a sublink in a target column subscript |