Re: Restructured Shared Buffer Hash Table

From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Dhruv Aron <dhruv(dot)aron(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, haoyu(dot)huang(dot)68(at)gmail(dot)com, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>
Subject: Re: Restructured Shared Buffer Hash Table
Date: 2026-08-11 22:08:44
Message-ID: CAE8JnxPC5bT_2CzT-hQgmXK7=o7qrmabJEKP7pBjy3yFX+3Kxw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 11, 2026 at 9:50 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Sspinlocks (neither plain ones nor the buffer header lock variant) have no
> error recovery whatsoever, so any error that is thrown will make the
system
> unusable.

This is a much better reason for not doing complex stuf under the spin lock,
not the number of instruction, but guarantees of safety.

> I don't really understand the race condition this is trying to address:
> > + /* Unlock buffer header after the entry is deleted to avoid a
race condition:

My guess:
Assume we have one bucket a: [a1, a2, a3], and bucket b: [b1]
- invalidate a1
- unlock a1
- reuse a1 as b2
now bucket a will see [a1, b2]
deletion will fail to find a2
Now buckets a and b are linked (in an invalid way).

> You can't just change the nesting in one place, you'd have to change it
> everywhere

Dhruv's patch doesn't change the nesting order. But that is an important
point.

Regards,
Alexandre

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2026-08-11 22:10:42 Re: Restructured Shared Buffer Hash Table
Previous Message Nathan Bossart 2026-08-11 21:45:49 Re: problems with toast.* reloptions