Horton
Menu

Re: Assertion failure in hash_kill_items()

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andres Freund <andres@anarazel.de>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Alexander Kuzmenkov <akuzmenkov@tigerdata.com>, Ashutosh Sharma <ashu.coek88@gmail.com>
Date: 2026-04-07T14:38:36Z
Lists: pgsql-hackers 
On 17/03/2026 19:40, Andres Freund wrote:
> On 2026-03-17 19:15:10 +0200, Heikki Linnakangas wrote:
>> The second patch simplifies the condition in the 'unlock_page' part. This
>> isn't new, and isn't needed to fix the bug, it just caught my eye while
>> looking at this. I don't understand why the condition was the way it was,
>> checking just 'havePin' seems sufficient and more correct to me. Am I
>> missing something?
> 
> I can't see anything either, quite odd.  Most likely explanation seems to be
> that something changed during the development of 7c75ef571579.
> 
> 
> Indeed, the first version of the patch from
>     https://postgr.es/m/CAE9k0Pm3KTx93K8_5j6VMzG4h5F%2BSyknxUwXrN-zqSZ9X8ZS3w%40mail.gmail.com
> was using "if (so->hashso_bucket_buf == so->currPos.buf)" both at the start
> and end of _hash_kill_items(). So likely it was just an accident during patch
> revisions.

Thanks for archeological excavation; pushed this second patch now.

- Heikki

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix harmless leftover in _hash_kill_items()

  2. Fix use of wrong variable in _hash_kill_items()