Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted |
Дата | |
Msg-id | 20201015.104248.2052383383680508195.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-bugs |
Ouch. You beat me to it. At Thu, 15 Oct 2020 14:26:36 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in > On Thu, Oct 15, 2020 at 8:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.munro@gmail.com> writes: > > > On Wed, Oct 14, 2020 at 5:35 PM Andres Freund <andres@anarazel.de> wrote: > > >> 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. > > > > +1, I was also thinking that. It'd be pretty easy to fit into the > > existing system structure (I think, without having looked at the relevant > > code lately), and it would not add any overhead to normal processing. > > Installing a timeout to handle this per Andres' idea inevitably *would* > > add overhead. > > Alright, here is a first swing at making our behaviour more consistent > in two ways: > > 1. The first segment should be truncated even in recovery. > 2. Later segments should be truncated on commit. > > I don't know why the existing coding decides not to try to unlink the > later segments if the truncate of segment 0 failed. We already > committed, we should plough on. I was trying the almost the same thing except how to emit the error message for truncation and not trying to unlink if truncation ends with ENOENT for following segments. regareds. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: