| 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
| 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 |