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+hUKGJd4MF38LxXtGY2CQ6yNwz9=fdsCEZOFAruv8caUfcKFw@mail.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>) |
| Ответы |
Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
|
| Список | pgsql-hackers |
On Tue, Dec 1, 2020 at 3:55 PM Michael Paquier <michael@paquier.xyz> wrote: > 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. I felt on balance it was a "bug", since it causes operational difficulties for people and was clearly not our intended behaviour, and I announced this intention 6 weeks ago. Of course I'll be happy to revert it from the back-branches if that's the consensus. Any other opinions?
В списке pgsql-hackers по дате отправления: