Hi,
On 2024-10-30 10:47:35 -0700, Jeff Davis wrote:
> 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.
What I am proposing isn't making the content lock more complicated, it's
orthogonal to the content lock.
> 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
It's possible, but it'd be a lot of work. And you wouldn't need to just do
this for heap, but all the indexes too, to make progress on the
don't-set-hint-bits-during-io front. So I don't think it makes sense to tie
these things together.
I do think that it's an argument for not importing all the complexity into
lwlock.c though.
> We would still have pins and cleanup locks to prevent data removal.
As-is cleanup locks only work in coordination with content locks. While
cleanup is ongoing we need to prevent anybody from starting to look at the
page - without acquiring something like a shared lock that's not easy.
> 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?
I don't think anything fundamental, but it's a decidedly nontrivial amount of
work.
Greetings,
Andres Freund
