Re: making relfilenodes 56 bits
От | Thomas Munro |
---|---|
Тема | Re: making relfilenodes 56 bits |
Дата | |
Msg-id | CA+hUKGLiWHWD5hdZ0Pb0iQGbMk7ue7O+NvhnYggS77M0H4E8zA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: making relfilenodes 56 bits (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: making relfilenodes 56 bits
|
Список | pgsql-hackers |
On Wed, Sep 28, 2022 at 9:40 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > Thanks, Thomas, these all look fine to me. So far we have committed > the patch to make relfilenode 56 bits wide. The Tombstone file > removal patch is still pending to be committed, so when I will rebase > that patch I will accommodate all these comments in that patch. I noticed that your new unlinking algorithm goes like this: stat("x") stat("x.1") stat("x.2") stat("x.3") -> ENOENT /* now we know how many segments there are */ truncate("x.2") unlink("x.2") truncate("x.1") unlink("x.1") truncate("x") unlink("x") Could you say what problem this solves, and, guessing that it's just that you want the 0 file to be "in the way" until the other files are gone (at least while we're running; who knows what'll be left if you power-cycle), could you do it like this instead? truncate("x") truncate("x.1") truncate("x.2") truncate("x.3") -> ENOENT /* now we know how many segments there are */ unlink("x.2") unlink("x.1") unlink("x")
В списке pgsql-hackers по дате отправления: