Date: Tue, 1 Dec 2020 11:55:34 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: BUG #16663: DROP INDEX did not free up disk space: idle
 connection hold file marked as deleted
Message-ID: <X8WwpscE7CT9UPHD@paquier.xyz>
References: <16663-fe97ccf9932fc800@postgresql.org>
 <160624299337.7563.13562988821961887884.pgcf@coridan.postgresql.org>
 <160624435783.7564.2550264874132085886.pgcf@coridan.postgresql.org>
 <CA+hUKGKbtf_mpxEuUpJt5oZAibYa=cVJ2wB4+NnnkbHfF5jCHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="0WV0HWMywBx2KoND"
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKGKbtf_mpxEuUpJt5oZAibYa=cVJ2wB4+NnnkbHfF5jCHQ@mail.gmail.com>
Precedence: bulk


--0WV0HWMywBx2KoND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Nov 30, 2020 at 06:59:40PM +1300, Thomas Munro wrote:
> 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.

Hmm.  Sorry for arriving late at the party.  But is that really
something suitable for a backpatch?  Sure, it is not optimal to not
truncate all the segments when a transaction dropping a relation
commits, but this was not completely broken either.
--
Michael

--0WV0HWMywBx2KoND
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl/FsKYACgkQnvQgOdby
QH2DAA//QN771t7/K9OYKYWyQ5OKtmJfYAo0ZKuj0DhjviYddDUfv+oHserwpzlS
MnltDpN/i1kmMgr0i8Vmw9wLDgbLg51Q+LeVUhHUISYf034Qyd+/Xw6Jku8DyBDF
YB5WDud/38KSfC8PvaiFQ9sx19yJNxRrlmybwiEBlgl3NmYYVaOkg41G+Q6vy8Ds
RF7kJlHogEE9QmxA+7XUQ6Aj0dfoy9RxSqYh0xoCoVU5saGPUg9ENponv5VipMlR
juCJ6v+X9OSIZFcqVLMiyM8ZJWICsxLgIn6VqCBJ5q2Z5JC71R2uxgSZ2eOuaDh+
cOxnWmQCVkMOno4Ouv6VkxPcFuCJHrXNayK0j/Kk1YL9JJPgZkFOmIzKdrfaRYhj
62qZo0OszJvA8/SjyXTE/EvhHO0kcKBFAKbM1RSC4uQxWyMO4zxYxALBXlSUyVo3
V6V/VV5TKdWB0MGN1hz65JMPcCz/Ubvjtd7uu0vwv7u2zQU2zY5jE9D4DCd/O1wl
x4ICZWDGyE+KSU3L+BkpXwyulvcsRlQC6fLOGcjZz1c3a0ZGDt+jFt0A/JCSx/Uv
Zm/XtsYNZrBvuiT5Y6y8rwOgZIEJcaULr8+uA6lSI/RHw3M2kleIzItUa5WkZt+k
zMVfQ7gEmmQD0migW+2iTsYYOrx1qinN2Cyv7wK8/addHcO0nYw=
=gsVz
-----END PGP SIGNATURE-----

--0WV0HWMywBx2KoND--