Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Date
Msg-id CA+hUKGKbtf_mpxEuUpJt5oZAibYa=cVJ2wB4+NnnkbHfF5jCHQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted  (Thomas Munro <thomas.munro@gmail.com>)
Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Nov 25, 2020 at 8:00 AM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> The new status of this patch is: Ready for Committer

Thanks!  One small thing bothered me about the last version of the
patch.  It tried to unlink when ENOENT had already been enountered by
open(2), so COMMIT of a DROP looks like:

openat(AT_FDCWD, "base/14208/16384", O_RDWR) = 54
ftruncate(54, 0)                        = 0
close(54)                               = 0
openat(AT_FDCWD, "base/14208/16384.1", O_RDWR) = -1 ENOENT
unlink("base/14208/16384.1")            = -1 ENOENT
openat(AT_FDCWD, "base/14208/16384_fsm", O_RDWR) = -1 ENOENT
unlink("base/14208/16384_fsm")          = -1 ENOENT
openat(AT_FDCWD, "base/14208/16384_vm", O_RDWR) = -1 ENOENT
unlink("base/14208/16384_vm")           = -1 ENOENT
openat(AT_FDCWD, "base/14208/16384_init", O_RDWR) = -1 ENOENT
unlink("base/14208/16384_init")         = -1 ENOENT

So I fixed that, by adding a return value to do_truncate() and
checking it.  That's the version I plan to commit tomorrow, unless
there are further comments or objections.  I've also attached a
version suitable for REL_11_STABLE and earlier branches (with a name
that cfbot should ignore), where things are slightly different.  In
those branches, the register_forget_request() logic is elsewhere.

While looking at trace output, I figured we should just use
truncate(2) on non-Windows, on the master branch only.  It's not like
it really makes much difference, but I don't see why we shouldn't
allow ourselves to use ancient standardised Unix syscalls when we can.
That'd get us down to just the following when committing a DROP:

truncate("base/14208/16396", 0)         = 0
truncate("base/14208/16396.1", 0)       = -1 ENOENT
truncate("base/14208/16396_fsm", 0)     = -1 ENOENT
truncate("base/14208/16396_vm", 0)      = -1 ENOENT
truncate("base/14208/16396_init", 0)    = -1 ENOENT

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: proposal: function pg_setting_value_split() to parse shared_preload_libraries etc.
Next
From: Fujii Masao
Date:
Subject: Re: Feature improvement for pg_stat_statements