Re: Buffer locking is special (hints, checksums, AIO writes)
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Buffer locking is special (hints, checksums, AIO writes) |
| Дата | |
| Msg-id | 8926bc6a-cab3-4edf-acf2-02b4cbeb7c9b@iki.fi обсуждение исходный текст |
| Ответ на | Re: Buffer locking is special (hints, checksums, AIO writes) (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
On 02/12/2025 15:20, Andres Freund wrote: > On 2025-12-02 10:01:06 +0200, Heikki Linnakangas wrote: >> But speaking of that: why do we not allow two processes to concurrently set >> hint bits on a page anymore? > > It'd make the locking a lot more complicated without much of a benefit. > > The new share-exclusive lock mode only requires one additional bit of lock > state, for the single allowed holder. If we wanted a new lockmode that > prevented the page from being written out concurrently, but could be held > multiple times, we'd need at least MAX_BACKENDS bits for the lock level > allowing hint bits to be set and another lock level to acquire while writing > out the buffer. > > At the same time, there seems to be little benefit in setting hint bits on a > page concurrently. A very common case is that the same hint bit(s) would be > set by multiple backends, we don't gain anything from that. And in the cases > where hint bits were intended to be set for different tuples, the window in > which that is not allowed is very narrow, and the cost of not setting right in > that moment is pretty small and the cost of not setting the hint bit right > then and there isn't high. > > Makes sense? Yep, makes sense. Would be good to put that in a comment somewhere, and in the commit message. "We could allow multiple backends to set hint bits concurrently, but it'd make the lock implementation more complicated" - Heikki
В списке pgsql-hackers по дате отправления: