Re: DropRelFileLocatorBuffers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: DropRelFileLocatorBuffers
Date
Msg-id CA+TgmoYT-9H7Z90zCDcD6jQL_Tv7FgNnCEtqOyTTrigNoOacKg@mail.gmail.com
Whole thread Raw
In response to Re: DropRelFileLocatorBuffers  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: DropRelFileLocatorBuffers
List pgsql-hackers
On Fri, Jul 8, 2022 at 1:59 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> I thought for a moment that "Relation" sounded better but that naming
> is confusing in bufmgr.c, where functions take Relation and those take
> RelFileLocator exist together. So the (second) attached introduces
> "RelFile" to represent RelFileNode excluding RelFileLocator.
>
> The function CreateAndCopyRelationData exists since before b0a55e4329
> but renamed since it takes RelFileLocators.

I'm not very sold on this. I think that the places where you've
replaced RelFileLocator with just RelFile in various functions might
be an improvement, but the places where you've replaced Relation with
RelFile seem to me to be worse. I don't really see that there's
anything wrong with names like CreateAndCopyRelationData or
FlushRelationsAllBuffers, and in general I prefer function names that
are made up of whole words rather than parts of words.

> While working on this, I found that the following coment is wrong.
>
>  *              FlushRelationsAllBuffers
>  *
>  *              This function flushes out of the buffer pool all the pages of all
>  *              forks of the specified smgr relations.  It's equivalent to calling
>  *              FlushRelationBuffers once per fork per relation.  The relations are
>  *              assumed not to use local buffers.
>
> It is equivalent to calling FlushRelationBuffers "per relation". This
> is attached as the first patch, which could be thought as a separate
> patch.

I committed this.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: EINTR in ftruncate()
Next
From: Tom Lane
Date:
Subject: Re: automatically generating node support functions