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+hUKGLj0jzP4vSq0unHPcaMMWGfmmcyhqmpFhar6G+Q_+LcUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
|
Список | pgsql-bugs |
On Wed, Oct 14, 2020 at 5:35 PM Andres Freund <andres@anarazel.de> wrote: > On 2020-10-14 12:05:10 +0900, Kyotaro Horiguchi wrote: > > At the time a relation including an index is dropped, the first > > segment file (named as "<id>" without a suffix number) is left behind > > so the file is not shown as "(deleted)" in lsof output. > > I think we should consider either occasionally sending a sinval catchup > interrupt to backends that have been idle for a while, or to use a timer > that we use to limit the maximum time until we process sinvals. Just > having to wait till all backends become busy and process sinval events > doesn't really seem like good approach to me. Oops, I also replied to this but now I see that I accidentally replied only to Horiguchi-san and not the list! I was thinking that we should perhaps consider truncating the files to give back the disk space (as we do for the first segment), so that it doesn't matter so much how long other backends take to process SHAREDINVALSMGR_ID, close their descriptors and release the inode.
В списке pgsql-bugs по дате отправления: