On Fri, Mar 4, 2022 at 12:37 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> 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.
Anyone else have an opinion on this?
> 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.
You're talking here about just needing to introduce BufTagGetFileNode
and BufTagSetFileNode, or something else? I don't find those macros to
be problematic.
BufTagSetFileNode could maybe assert that the OID isn't too big,
though. We should ereport() before we get to this point if we somehow
run out of values, but it might be nice to have a check here as a
backup.
--
Robert Haas
EDB: http://www.enterprisedb.com