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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Дата
Msg-id CA+hUKGKbtf_mpxEuUpJt5oZAibYa=cVJ2wB4+NnnkbHfF5jCHQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted  (Pavel Borisov <pashkin.elfe@gmail.com>)
Ответы Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Список 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

Вложения

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: proposal: function pg_setting_value_split() to parse shared_preload_libraries etc.
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Feature improvement for pg_stat_statements