Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nlVbh-0002df-3H for pgsql-hackers@arkaria.postgresql.org; Mon, 02 May 2022 12:56:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nlVbf-0003R7-Rb for pgsql-hackers@arkaria.postgresql.org; Mon, 02 May 2022 12:56:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nlVbf-0003Qx-H9 for pgsql-hackers@lists.postgresql.org; Mon, 02 May 2022 12:56:51 +0000 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nlVbb-0007Az-RT for pgsql-hackers@lists.postgresql.org; Mon, 02 May 2022 12:56:51 +0000 Received: by mail-pf1-x429.google.com with SMTP id h1so12208817pfv.12 for ; Mon, 02 May 2022 05:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HJstXeJhQ4p6q0lkhmBn3QdmpjaantsCAZyMF/U6Dcg=; b=N7YU2iipeRkN/5ipCwNOa3AiWUoPcV572vm5hDKyyYqNuN3yTHr1n1upy1FgwpToKD o4eV2Rageh8Ma2XL190homrozd+4olFUxgLpk19MG+lV2TmLXHyWGaTBnICkq7pvS2Is vKAhtK9yUF+AZH/Nf/LujwxJykNenOxEQWvO3HeWD8LwgAMwFSE15Pe1muPaHHertVvP lOv7N2CxMZXAzr+96uhE4HlQsZmj0HxzPGV+X+e6vTRz6eR6htPggLyeI5BwuHMYZwbd g2MU/8vEmtHmT/ZRWvRLjDFUuWz7Yk+52PYGgDnZjMsesfF3j1l45Cf1ndcW4hXOrbGS x4Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HJstXeJhQ4p6q0lkhmBn3QdmpjaantsCAZyMF/U6Dcg=; b=DeiwCEhVV5K+il579uhS9cSXj+4sfiHrsrSg7SS+4DoLbnz6/m7esNAqny13YaPd1C +wKrdi4yHrOdIpTTa84qE6RPCXkxQS9MW2qAos38ZmYogxYWeeTQJU0PW0pAK++QEEm9 7M3M0ZENLdlwVVXbsE6QdgZ56w/mQv3i5sRXDO3vKSrIkHghQi95weXcSpk4gQQu7nV8 ySsVFHY8rvCcB8o8xCeHqlW32bdbnksFjHsn7bAFsPLscL1AduHAwXpRP8x8GqxRGOWF gBvMb5NHFWz4fLRepGu9joX4YgJcqx1FdPOl+JfNPug/ZJRv47LrF1tDtGESQ5ki3xdP 2/IQ== X-Gm-Message-State: AOAM5330EKrUWhP9723+BzwNvliv9uK3EvudHqTQvBnXwxWlO0LTRuIg GYiz1AENHCEtdzzxxrizmGTMXJkWvohU8o1qkvQ= X-Google-Smtp-Source: ABdhPJwAQ7SUKDL43KqZza35Zz4SnuP0DE+OZCGkZQmB/7N24hfIKaf2kE4eUa+H4Y940bKSe82GQXkRCI/Bu6ftOjA= X-Received: by 2002:a05:6a00:1a92:b0:50d:a348:6bc7 with SMTP id e18-20020a056a001a9200b0050da3486bc7mr10757596pfv.83.1651496205420; Mon, 02 May 2022 05:56:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ashutosh Bapat Date: Mon, 2 May 2022 18:26:33 +0530 Message-ID: Subject: Re: Progress report removal of temp files and temp relation files using ereport_startup_progress To: Bharath Rupireddy Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Bharath, On Sat, Apr 30, 2022 at 11:08 AM Bharath Rupireddy wrote: > > Hi, > > At times, there can be many temp files (under pgsql_tmp) and temp > relation files (under removal which after crash may take longer during > which users have no clue about what's going on in the server before it > comes up online. > > Here's a proposal to use ereport_startup_progress to report the > progress of the file removal. > > Thoughts? The patch looks good to me. With this patch, the user would at least know which directory is being scanned and how much time has elapsed. It would be better to know how much work is remaining. I could not find a way to estimate the number of files in the directory so that we can extrapolate elapsed time and estimate the remaining time. Well, we could loop the output of opendir() twice, first to estimate and then for the actual work. This might actually work, if the time to delete all the files is very high compared to the time it takes to scan all the files/directories. Another possibility is to scan the sorted output of opendir() thus using the current file name to estimate remaining files in a very crude and inaccurate way. That doesn't look attractive either. I can't think of any better way to estimate the remaining time. But at least with this patch, a user knows which files have been deleted, guessing how far, in the directory structure, the process has reached. S/he can then take a look at the remaining contents of the directory to estimate how much it should wait. -- Best Wishes, Ashutosh Bapat