Re: Make relfile tombstone files conditional on WAL level

On Mon, Feb 21, 2022 at 1:21 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Thu, Jan 6, 2022 at 1:43 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 2) GetNewRelFileNode() will not loop for checking the file existence
> > and retry with other relfilenode.
>
>
> Open Issues- there are currently 2 open issues in the patch 1) Issue
> as discussed above about removing the loop, so currently in this patch
> the loop is removed. 2) During upgrade from the previous version we
> need to advance the nextrelfilenode to the current relfilenode we are
> setting for the object in order to avoid the conflict.

In this version I have fixed both of these issues. Thanks Robert for
suggesting the solution for both of these problems in our offlist
discussion. Basically, for the first problem we can flush the xlog
immediately because we are actually logging the WAL every time after
we allocate 64 relfilenode so this should not have much impact on the
performance and I have added the same in the comments. And during
pg_upgrade, whenever we are assigning the relfilenode as part of the
upgrade we will set that relfilenode + 1 as nextRelFileNode to be
assigned so that we never generate the conflicting relfilenode.

The only part I do not like in the patch is that before this patch we
could directly access the buftag->rnode. But since now we are not
having directly relfilenode as part of the buffertag and instead of
that we are keeping individual fields (i.e. dbOid, tbsOid and relNode)
in the buffer tag. So if we have to directly get the relfilenode we
need to generate it. However those changes are very limited to just 1
or 2 file so maybe not that bad.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com