Re: AIO writes vs hint bits vs checksums

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: AIO writes vs hint bits vs checksums
Дата
Msg-id 6886ce07fed3da018b043dab6bab025db40e9e12.camel@j-davis.com
обсуждение исходный текст
Ответ на AIO writes vs hint bits vs checksums  (Andres Freund <andres@anarazel.de>)
Ответы Re: AIO writes vs hint bits vs checksums
Список pgsql-hackers
On Tue, 2024-09-24 at 11:55 -0400, Andres Freund wrote:
> What I suspect we might want instead is something inbetween a share
> and an
> exclusive lock, which is taken while setting a hint bit and which
> conflicts
> with having an IO in progress.

I am starting to wonder if a shared content locks are really the right
concept at all. It makes sense for simple mutexes, but we are already
more complex than that, and you are suggesting adding on to that
complexity. Which I agree is a good idea, I'm just wondering if we
could go even further.

The README states that a shared lock is necessary for visibility
checking, but can we just be more careful with the ordering and
atomicity of visibility changes in the page?

 * carefully order reads and writes of xmin/xmax/hints (would
   that create too many read barriers in the tqual.c code?)
 * write line pointer after tuple is written

We would still have pins and cleanup locks to prevent data removal.
We'd have the logic you suggest that would prevent modification during
IO. And there would still need to be an exclusive content locks so that
two inserts don't try to allocate the same line pointer, or lock the
same tuple.

If PD_ALL_VISIBLE is set it's even simpler.

Am I missing some major hazards?

Regards,
    Jeff Davis




В списке pgsql-hackers по дате отправления: