Re: Make relfile tombstone files conditional on WAL level

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Make relfile tombstone files conditional on WAL level
Дата
Msg-id CAFiTN-tfRGVSzzEocegOm4s7bbaT6VKmO8WrAfTdH_M6wjR-Bw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Make relfile tombstone files conditional on WAL level  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Make relfile tombstone files conditional on WAL level
Re: Make relfile tombstone files conditional on WAL level
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Design of pg_stat_subscription_workers vs pgstats
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Patch a potential memory leak in describeOneTableDetails()