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.89) (envelope-from ) id 1iuPFg-0007pA-4W for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2020 23:17:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iuPFe-00045r-TT for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2020 23:17:34 +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 1iuPFe-00043o-D4 for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2020 23:17:34 +0000 Received: from mail-yw1-xc42.google.com ([2607:f8b0:4864:20::c42]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iuPFZ-0004lG-Jf for pgsql-hackers@postgresql.org; Wed, 22 Jan 2020 23:17:33 +0000 Received: by mail-yw1-xc42.google.com with SMTP id i126so665238ywe.7 for ; Wed, 22 Jan 2020 15:17:29 -0800 (PST) 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=Ago+lHKcXgO1oI3uGo9fFUkSK6r+8n+U/YUKh51TjBk=; b=gyl8U/tpJIKy5ibjnGjoIFaf8mpEGxpoaLq22zvYZFAPwk8drQSY1aup15ZsGLjjOj mjyY0OcCGB8l5RKpErBkOi48xgHzWopvHqwW2brwgjVV+yT2sQD15N6HLeGcBuekX9lJ GMx2BJdr/mIngChVyvr8HycM8SfWC8EHcz+V9XOdGsiSINCEiE7j4jvRsDYkjl17p8M9 1kNuSnjhRGrco9TC3dz0el71YDOYtIX622xwCn1QxDRCP4HHrk+q+Pw0MfNnt8fHOziV ak4H0o7/ov5iHzHAD7ALmmYeJgtxCxXwXN1vlNbRQLqaUWTxVY+E9Pd9+dcoQW6y82br L3CQ== 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=Ago+lHKcXgO1oI3uGo9fFUkSK6r+8n+U/YUKh51TjBk=; b=AYbYneW9bz9cgiMCIXnj7bSewS337XK8Z69+JnEKtu34C7TGHL3r9mmmoL1ry0pVrl M/7te2P2DJB1YbehA9isfATr75a560tvizJN7mLv5V5m6Jb1c5/eSJe00sF5Vh1d4f// j39iOUiYiyrcMQjkO1fcinKTxalI1Q+GpFM7yt2tMUggoLgJ2B65VYyro2ifoAt7GMrQ j3tCLl502mElwy4kLUfaC7SBp8WgJ0SMIOXh2Va1ILZU3JIvA03aQV2DdS0nXnL7Rb5V VWBM8TG5rQTE41O37S/Tt5vzDaRtOlOie4EB7lpYcDWfANZXvgiwRdgeDtAQEqa0SvGq tWkw== X-Gm-Message-State: APjAAAWR/YXDYAjNgm/9pev2NehBtxXLWhieVOae5iSXtYc4EreRTYzJ K/miMMh8CCu0teMtaKbE3jp1jQ== X-Google-Smtp-Source: APXvYqwmeBetZY1U4lutEZ+aBkKeeYNpasHxmWESpk5x77W8F2wjVvxjRHru1mD26JBMyUESkuT1ZQ== X-Received: by 2002:a81:9a4d:: with SMTP id r74mr8799150ywg.79.1579735048516; Wed, 22 Jan 2020 15:17:28 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id i17sm19695078ywg.66.2020.01.22.15.17.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 15:17:27 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 1DC00800831; Wed, 22 Jan 2020 17:17:26 -0600 (CST) Date: Wed, 22 Jan 2020 17:17:26 -0600 From: Justin Pryzby To: Andres Freund Cc: Michael Paquier , Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: error context for vacuum to include block number Message-ID: <20200122231725.GI13621@telsasoft.com> References: <20191213224735.GY2082@telsasoft.com> <20191215130708.GA19063@paquier.xyz> <20191215162712.GZ2082@telsasoft.com> <20191216024956.GC2344@paquier.xyz> <20191224012428.GK30414@telsasoft.com> <20191224041909.GA323806@paquier.xyz> <20191226155704.GA12890@telsasoft.com> <20200102162701.GA2709@telsasoft.com> <20200120054159.GT26045@telsasoft.com> <20200120191120.s2pyx4ib4yubavxe@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200120191120.s2pyx4ib4yubavxe@alap3.anarazel.de> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jan 20, 2020 at 11:11:20AM -0800, Andres Freund wrote: > > @@ -966,8 +986,11 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats, > > /* Work on all the indexes, then the heap */ > > + /* Don't use the errcontext handler outside this function */ > > + error_context_stack = errcallback.previous; > > lazy_vacuum_all_indexes(onerel, Irel, indstats, > > vacrelstats, lps, nindexes); > > + error_context_stack = &errcallback; > > Alternatively we could push another context for each index inside > lazy_vacuum_all_indexes(). There's been plenty bugs in indexes > triggering problems, so that could be worthwhile. Is the callback for index vacuum useful without a block number? FYI, I have another patch which would add DEBUG output before each stage, which would be just as much information, and without needing to use a callback. It's 0004 here: https://www.postgresql.org/message-id/20200121134934.GY26045%40telsasoft.com @@ -1752,9 +1753,12 @@ lazy_vacuum_all_indexes(Relation onerel, Relation *Irel, { int idx; - for (idx = 0; idx < nindexes; idx++) + for (idx = 0; idx < nindexes; idx++) { + ereport(DEBUG1, (errmsg("\"%s\": vacuuming index", + RelationGetRelationName(Irel[idx])))); lazy_vacuum_index(Irel[idx], &stats[idx], vacrelstats->dead_tuples,