From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: making relfilenodes 56 bits |
Date: | 2022-09-28 22:53:02 |
Message-ID: | CA+hUKGLiWHWD5hdZ0Pb0iQGbMk7ue7O+NvhnYggS77M0H4E8zA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 28, 2022 at 9:40 PM Dilip Kumar <dilipbalaut(at)gmail(dot)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")
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-28 22:56:20 | Re: identifying the backend that owns a temporary schema |
Previous Message | Nathan Bossart | 2022-09-28 21:08:28 | Re: Refactor UnpinBuffer() |