Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jHKLa-000647-DB for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Mar 2020 04:42:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jHKKZ-0002v7-R3 for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Mar 2020 04:41:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jHKKZ-0002sK-6F for pgsql-hackers@lists.postgresql.org; Thu, 26 Mar 2020 04:41:23 +0000 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jHKKV-0006Zf-FF for pgsql-hackers@postgresql.org; Thu, 26 Mar 2020 04:41:21 +0000 Received: by mail-qk1-x72e.google.com with SMTP id i6so5240132qke.1 for ; Wed, 25 Mar 2020 21:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IEoaUFFNI0DOUDo+Zi7hr3XCYQBf6PHFADDKjx8We1Y=; b=GlKipkPsRXvT8gUVhxP0lXPWs1dUY710OGTrw9vwYf0YTcNNwplBGbxtqv7lgp6LHa Vb0PeJy+Iq/4joiqNhx8snPNwWBdYo+ff8G6YF238eDtN43e7Op+3tehtbm8GxiV5X1r UEHX7gc5GxjZ2Qs1jjMc654UC9SaUuHwRCXaTNEhPV4+3nVZeI90ruP0Xb2fUUIN5mF+ vFseZplQGbgdDU9KQPdAmp60vsW8pPI6ual789fAVsFBl61iMk4LJ7sT2PBmNPvDF9VY fOakFgOvvwkTRBuwOMhky7dInt478NsVxD4bK47OMsla9ZGQi9KtntOFKKpA0RvtjqoP bwrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=IEoaUFFNI0DOUDo+Zi7hr3XCYQBf6PHFADDKjx8We1Y=; b=pQ4lz5uQd+MgxeFuT0U9UJ2res9yBKQ6tZIzBm2V0L8oCJkhfFJKszp91BGgWinGS8 OAiYSCt6yWm21VfZTJue61qWwgxztzQGT0X9g+ZSYbWlpsSWnZwccDmU6JD5oUzzQ1w0 LXbMrv1Cq7hdGEl0T8i0j8+exTCCJvvVQ1FyuBFQrHulTKp0BFZbAjSTG8XccSF7O5WQ Gi3ISiGSOz/4oz03q2lKHL9XyJemRFAYGt2NKG0WJgiQdC8AHhkiv9Y+xI2czgVlKht/ kJjJA25Fe+alKEnUfLooQX8onJoVemipErVgRTqh96HkEnIkwXdesQvv04h2EPMT7OA3 UrdA== X-Gm-Message-State: ANhLgQ2qNl1Jq/+ypqHI7TTFfSmk81ptMCSVQYyAkmh6ZJ/PWyxh/p05 7th0rDTdsUa3sDuPlXJE9JR9hg== X-Google-Smtp-Source: ADFU+vvnjl+KD3eixYeLK452+nna4hLHyybGhk3KnQ4BK8NpfHjM4QMqyGZvYRc49QarGTMvpBGEyw== X-Received: by 2002:a37:a749:: with SMTP id q70mr6253161qke.226.1585197678285; Wed, 25 Mar 2020 21:41:18 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id h11sm804062qta.44.2020.03.25.21.41.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 21:41:17 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id BBA2A800EBC; Wed, 25 Mar 2020 23:41:15 -0500 (CDT) Date: Wed, 25 Mar 2020 23:41:15 -0500 From: Justin Pryzby To: Amit Kapila Cc: Masahiko Sawada , Alvaro Herrera , Andres Freund , Michael Paquier , pgsql-hackers Subject: Re: error context for vacuum to include block number Message-ID: <20200326044115.GB28385@telsasoft.com> References: <20200325101229.GR21443@telsasoft.com> <20200325124155.GU21443@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Mar 26, 2020 at 09:50:53AM +0530, Amit Kapila wrote: > > > after count_nondeletable_pages, and then revert it back to > > > VACUUM_ERRCB_PHASE_SCAN_HEAP phase and the number of blocks of > > > relation before truncation, after RelationTruncate(). It can be > > > repeated until no more truncating can be done. Why do we need to > > > revert back to the scan heap phase? If we can use > > > vacrelstats->nonempty_pages in the error context message as the > > > remaining blocks after truncation I think we can update callback > > > arguments once at the beginning of lazy_truncate_heap() and don't > > > revert to the previous phase, and pop the error context after exiting. > > > > Perhaps. We need to "revert back" for the vacuum phases, which can be called > > multiple times, but we don't need to do that here. > > Yeah, but I think it would be better if are consistent because we have > no control what the caller of the function intends to do after > finishing the current phase. I think we can add some comments where > we set up the context (in heap_vacuum_rel) like below so that the idea > is more clear. > > "The idea is to set up an error context callback to display additional > information with any error during vacuum. During different phases of > vacuum (heap scan, heap vacuum, index vacuum, index clean up, heap > truncate), we update the error context callback to display appropriate > information. > > Note that different phases of vacuum overlap with each other, so once > a particular phase is over, we need to revert back to the old phase to > keep the phase information up-to-date." Seems fine. Rather than saying "different phases" I, would say: "The index vacuum and heap vacuum phases may be called multiple times in the middle of the heap scan phase." But actually I think the concern is not that we unnecessarily "Revert back to the old phase" but that we do it in a *loop*. Which I agree doesn't make sense, to go back and forth between "scanning heap" and "truncating". So I think we should either remove the "revert back", or otherwise put it after/outside the "while" loop, and change the "return" paths to use "break". -- Justin