Message-ID: <c2c36dd0-aee4-8c82-4f86-f613d416d0b7@enterprisedb.com>
Date: Mon, 3 Apr 2023 14:25:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: hio.c does visibilitymap_pin()/IO while holding buffer lock
Content-Language: en-US
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Tomas Vondra <tv@fuzzy.cz>,
 Anastasia Lubennikova <lubennikovaav@gmail.com>,
 Pavan Deolasee <pavan.deolasee@gmail.com>, Jeff Janes <jeff.janes@gmail.com>
References: <20230325025740.wzvchp2kromw4zqz@awork3.anarazel.de>
 <0c11032a-d91b-8875-ab7b-4554776390c5@enterprisedb.com>
 <20230325163903.eu67kqcqo4llhc4u@awork3.anarazel.de>
 <2602455.1679763437@sss.pgh.pa.us>
 <20230325181707.at3kwsh7uvkhfype@awork3.anarazel.de>
 <20230329012102.zpviu2e7kyfrovxn@awork3.anarazel.de>
 <20230329021721.l3rujmv3jjmktt5i@awork3.anarazel.de>
 <20230402224024.aealekgu2df4cnhs@awork3.anarazel.de>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <20230402224024.aealekgu2df4cnhs@awork3.anarazel.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/c2c36dd0-aee4-8c82-4f86-f613d416d0b7%40enterprisedb.com>
Precedence: bulk

On 4/3/23 00:40, Andres Freund wrote:
> Hi,
> 
> On 2023-03-28 19:17:21 -0700, Andres Freund wrote:
>> On 2023-03-28 18:21:02 -0700, Andres Freund wrote:
>>> Here's a draft patch.
>>
>> Attached is v2, with a stupid bug fixed and a bit of comment / pgindent
>> polish.
> 
> I'd welcome some review (Tomas?), but otherwise I'm planning to push ahead
> with this.
> 

I guess the 0001 part was already pushed, so I should be looking only at
0002, correct?

I think 0002 makes RelationGetBufferForTuple() harder to understand. I'm
not saying it's incorrect, but I find it hard to reason about the new
combinations of conditions :-(

I mean, it only had this condition:

    if (otherBuffer != InvalidBuffer)
    {
        ...
    }

but now it have

    if (unlockedTargetBuffer)
    {
       ...
    }
    else if (otherBuffer != InvalidBuffer)
    {
        ...
    }

    if (unlockedTargetBuffer || otherBuffer != InvalidBuffer)
    {
        ...
    }

Not sure how to improve that :-/ but not exactly trivial to figure out
what's going to happen.

Maybe this

 * If we unlocked the target buffer above, it's unlikely, but possible,
 * that another backend used space on this page.

might say what we're going to do in this case. I mean - I understand
some backend may use space in unlocked page, but what does that mean for
this code? What is it going to do? (The same comment talks about the
next condition in much more detail, for example.)

Also, isn't it a bit strange the free space check now happens outside
any if condition? It used to happen in the

    if (otherBuffer != InvalidBuffer)
    {
        ...
    }

block, but now it happens outside.

> I'm still debating with myself whether this commit (or a prerequisite commit)
> should move logic dealing with the buffer ordering into
> GetVisibilityMapPins(), so we don't need two blocks like this:
> 
> 
> 		if (otherBuffer == InvalidBuffer || targetBlock <= otherBlock)
> 			GetVisibilityMapPins(relation, buffer, otherBuffer,
> 								 targetBlock, otherBlock, vmbuffer,
> 								 vmbuffer_other);
> 		else
> 			GetVisibilityMapPins(relation, otherBuffer, buffer,
> 								 otherBlock, targetBlock, vmbuffer_other,
> 								 vmbuffer);
> ...
> 
> 		if (otherBuffer != InvalidBuffer)
> 		{
> 			if (GetVisibilityMapPins(relation, otherBuffer, buffer,
> 									 otherBlock, targetBlock, vmbuffer_other,
> 									 vmbuffer))
> 				unlockedTargetBuffer = true;
> 		}
> 		else
> 		{
> 			if (GetVisibilityMapPins(relation, buffer, InvalidBuffer,
> 									 targetBlock, InvalidBlockNumber,
> 									 vmbuffer, InvalidBuffer))
> 				unlockedTargetBuffer = true;
> 		}
> 	}
> 

Yeah. I haven't tried, but I imagine it'd make RelationGetBufferForTuple
a little bit.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company