Re: BUG #15427: DROP INDEX did not free up disk space

Hi,

On 2018-10-11 23:57:16 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-10-12 03:27:28 +0000, PG Bug reporting form wrote:
> >> Performed a DROP INDEX to free up disk space but, whilst the command
> >> succeeded the disk space was not freed up.
>
> > The problem here is that even though we send a invalidation message to
> > all backends, there's nothing to force backends to process invalidation
> > messages in time if they're idle.
>
> Uh, what's that got to do with it?

If you look at the bugreport: As soon as the op, on my suggestion,
triggered sinval processing (by issuing a SELECT 1;) the space was
freed. So clearly the open FDs were part of the problem.

> My recollection (though I've not looked at the code) is that we
> truncate the file to ensure disk space is freed, whether or not
> all backends have closed their FDs for the file.

That's not quite how we do it tho. In mdunlinkfork() we truncate the
*first* segment, but all further segments are unlink()ed directly. For
that to work, sinvals need to be processed. So

> This is quite independent of the sinval mechanism.

is clearly currently not correct.

I'd argue that even if we were to change mdunlinkfork() so it always
truncates and then unlinks, we should *still* make sure that sinval
messages for things like smgrdounlinkfork() are processed in some
bounded time. Consider e.g. that you might drop a table + tablespace and
then would want to unmount - this'd prevent that.

Greetings,

Andres Freund