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+hUKGKN00rs3QkE+TNeVK87yr8hRYy7tMcJM2tgieoZEJnOPQ@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  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Mon, Nov 30, 2020 at 6:59 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> 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

> ...  That's the version I plan to commit tomorrow, unless
> there are further comments or objections.  ...

Done, and back-patched.

I thought a bit more about the fact that we fail to unlink
higher-numbered segments in certain error cases, potentially leaving
stray files behind.  As far as I can see, nothing we do in this
code-path is going to be a bullet-proof solution to that problem.  One
simple idea would be for the checkpointer to refuse to unlink segment
0 (thereby allowing the relfilenode to be recycled) until it has
scanned the parent directory for any related files that shouldn't be
there.

> 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.

Also pushed, but only to master.



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist
Next
From: Tom Lane
Date:
Subject: Re: Huge memory consumption on partitioned table with FKs