Re: Make relfile tombstone files conditional on WAL level - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Make relfile tombstone files conditional on WAL level
Date
Msg-id CAFiTN-tfRGVSzzEocegOm4s7bbaT6VKmO8WrAfTdH_M6wjR-Bw@mail.gmail.com
Whole thread Raw
In response to Re: Make relfile tombstone files conditional on WAL level  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Make relfile tombstone files conditional on WAL level  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: Make relfile tombstone files conditional on WAL level  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jan 6, 2022 at 1:43 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

 2) GetNewRelFileNode() will not loop for checking the file existence
> and retry with other relfilenode.

While working on this I realized that even if we make the relfilenode
56 bits we can not remove the loop inside GetNewRelFileNode() for
checking the file existence.  Because it is always possible that the
file reaches to the disk even before the WAL for advancing the next
relfilenode and if the system crashes in between that then we might
generate the duplicate relfilenode right?

I think the second paragraph in XLogPutNextOid() function explain this
issue and now even after we get the wider relfilenode we will have
this issue.  Correct?

I am also attaching the latest set of patches for reference, these
patches fix the review comments given by Robert about moving the
dbOid, tbsOid and RelNode directly into the buffer tag.

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.

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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Patch a potential memory leak in describeOneTableDetails()