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 1if413-0003eu-Ex for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2019 15:35:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1if412-0006f4-6X for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2019 15:35:04 +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 1if411-0006bl-IW for pgsql-hackers@lists.postgresql.org; Wed, 11 Dec 2019 15:35:03 +0000 Received: from mail-ua1-x943.google.com ([2607:f8b0:4864:20::943]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1if40y-0004Of-Am for pgsql-hackers@postgresql.org; Wed, 11 Dec 2019 15:35:02 +0000 Received: by mail-ua1-x943.google.com with SMTP id v19so8225263uap.0 for ; Wed, 11 Dec 2019 07:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=L0w5Y3ZwpxZFHwSRNV25Q3+7C6JaZKcXwEhivOMPTK8=; b=PpMPsf85ssPln//RXt2eyDh0/NwUoSxu3rGSHA2DPa6KCuvyValk6hcJ+9AW8wCMuX Nj4ASWbHWjIbcm1FCnCDfZ0faq3zlHLnzWdLPqYpnbp3y+KFxTNw4onrn2G7ESO2AGoV uFQwm5tUW/DloezXMccxsl4ym4ZACy9SdsJIHbT04rGTn9RhVaeV5a2oFyYMIZ0uVc5i IyZ7nGdPYjvStqHE7e7lrzRYC10tp4+2nZqucyxU9ABNiuN+ejfpjQiYkbecSVJgGt5g tOwJz9BpQA6nXvCeMUtJzuzECjL1wC7Ww0ykBwWXEAgIcB9Ild4LJqwYJQ4gc6VZ0omh Ws8g== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=L0w5Y3ZwpxZFHwSRNV25Q3+7C6JaZKcXwEhivOMPTK8=; b=mn5F3dJZGWBaUXywky/bpKM24JWZT6E2RnIPgbFxOWAv4YWK0ceckPwUgcmBK5TORz SHfVKxy5n6Gnf9E0zVVgSLgyNqqBNWYFteSP9z9J3piHKvMN/x1pNuSP8OlHqcT7tyfz vSH3Gpw8+vSC+DupaicjF9EOprEZdao/JJ6nFXwHSa4Tag9A4EaVezd5UT703G4RvUyv MJ+kzC1urQKyjMHDtZaoseFYGtsFOxh3rvI4mjDHMwwrf8CIJRK0bFE0O56uA9H5dyOP w1yHbaSr7KhmSTUktrKhmWy+x4fXwySYcs8ydoi4Nl/2+8RWXNcyIuKOz3sd6rGpYLWe KXtQ== X-Gm-Message-State: APjAAAUsVJOwO4APZYq3s3GPnaD2ql6NF7Go+G9HVHa/6GcZGTv4Msdd FcT71+H24WQFxX8Zn6PXV/BOlJRIAsuWgA== X-Google-Smtp-Source: APXvYqxP3QqqxiTmJyr2C07kmnUnCCeaHpnwYlKE71UmnqR4ZNskYrVOsPoDk8INjVH+zLfEU84S0Q== X-Received: by 2002:ab0:3085:: with SMTP id h5mr3648644ual.110.1576078499144; Wed, 11 Dec 2019 07:34:59 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([190.95.19.128]) by smtp.gmail.com with ESMTPSA id s22sm1608487vkl.48.2019.12.11.07.34.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Dec 2019 07:34:58 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 05C483009ED; Wed, 11 Dec 2019 12:33:54 -0300 (-03) Date: Wed, 11 Dec 2019 12:33:53 -0300 From: Alvaro Herrera To: Justin Pryzby Cc: Michael Paquier , pgsql-hackers@postgresql.org, Andres Freund Subject: Re: error context for vacuum to include block number Message-ID: <20191211153353.GA23008@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191211143648.GK2082@telsasoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Dec-11, Justin Pryzby wrote: > @@ -635,6 +644,15 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats, > else > skipping_blocks = false; > > + /* Setup error traceback support for ereport() */ > + errcallback.callback = vacuum_error_callback; > + cbarg.relname = relname; > + cbarg.relnamespace = get_namespace_name(RelationGetNamespace(onerel)); > + cbarg.blkno = 0; /* Not known yet */ Shouldn't you use InvalidBlockNumber for this initialization? > @@ -658,6 +676,8 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats, > > pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno); > > + cbarg.blkno = blkno; I would put this before pgstat_progress_update_param, just out of paranoia. > @@ -817,7 +837,6 @@ lazy_scan_heap(Relation onerel, VacuumParams *params, LVRelStats *vacrelstats, > > buf = ReadBufferExtended(onerel, MAIN_FORKNUM, blkno, > RBM_NORMAL, vac_strategy); > - > /* We need buffer cleanup lock so that we can prune HOT chains. */ > if (!ConditionalLockBufferForCleanup(buf)) > { Lose this hunk? > @@ -2354,3 +2376,15 @@ heap_page_is_all_visible(Relation rel, Buffer buf, > > return all_visible; > } > + > +/* > + * Error context callback for errors occurring during vacuum. > + */ > +static void > +vacuum_error_callback(void *arg) > +{ > + vacuum_error_callback_arg *cbarg = arg; > + > + errcontext("while scanning block %u of relation \"%s.%s\"", > + cbarg->blkno, cbarg->relnamespace, cbarg->relname); > +} I would put this function around line 1512 (just after lazy_scan_heap) rather than at bottom of file. (And move its prototype accordingly, to line 156.) Or do you intend that this is going to be used for lazy_vacuum_heap too? Maybe it should. Patch looks good to me otherwise. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services