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 1k0150-0001Tr-1x for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jul 2020 11:14:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k014x-0000rK-6v for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jul 2020 11:13:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k014w-0000rC-Uw for pgsql-hackers@lists.postgresql.org; Mon, 27 Jul 2020 11:13:58 +0000 Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k014t-0002bI-0W for pgsql-hackers@postgresql.org; Mon, 27 Jul 2020 11:13:57 +0000 Received: by mail-io1-xd36.google.com with SMTP id l1so16478703ioh.5 for ; Mon, 27 Jul 2020 04:13:54 -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=rO+l8IJ6ODEcVqntUTK0RZYfST0z2rhqW03UfWjip/g=; b=LlNc8O5Y4d5wfjQfuJvzi38uHFGEGEXEiIF31UnsnImSYCG24kxIHZUsJYq/qWG98O Yj7t8wVVo0czv3bYBvS984dT2JL20J9I6XYryiU1lY9Hb7Cnep9OpZBQV/t0flYBwGhq zIZqgXXPTO0y+UXQ6x/BPQgHKB09iS3xH6l5YJcaw0mrEVW3Ss1k6AWKpGk1YlGAWUv4 huiOo7qtvMHOylxwxRYRiKljM2Pdgefy8z4p5Ko0EOs8Y2/eyq0otZMXletIPLiO/BVU z6z6+yYtjdHMtxFe+ov8qF6uUWk8dD3JOXA8xPQnuH3H4eTU1pxa1g1Jv5iVoeyZNr3K bf1Q== 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=rO+l8IJ6ODEcVqntUTK0RZYfST0z2rhqW03UfWjip/g=; b=pPutm4oT6Cj5fcSSZBRzYYh+Ifvv4ikON2yLqcE/m3kLwNBHr8ks1+Rilq9YgBOrAh Hd2pCK5ui9vyVaQb6LOcnrpnTTll2m9xtqFYCaV2YP+uTfCU+/e1W/8uZNEgHavldAUo zDYomGqdt3vnpcttdfjY36a9lFZFi4RHrYmNVo3GRrRM+WrUKmPP/BdcVsqY6KSlFUFf LR04uMzXbaBf82+dLvqpGsK+AT1YjkfuRQ/uzbdpKJW+tQ5Kt7+hfNxo74D2SlP3i0O9 0bRzq3uxQvc2986UlxiRZiON59NmnZegX04RqtJC9gLssJ2eTXOuo4sJPhX9tTiaxSl9 CFaA== X-Gm-Message-State: AOAM533COkcFZi28pL8D4VABsLmBvp92TRtoTk7noZQ+kbAIatE23x1M 1lqfriggS2X3CTS7LpuOx+o39w== X-Google-Smtp-Source: ABdhPJxjV5LHx2qzw85RDqnxQivSIALmrR3NLa4j2r3N0Ac/Af3MAb1dTNkkyoj/P+74itQKjNeTBg== X-Received: by 2002:a5d:8c8f:: with SMTP id g15mr16431705ion.206.1595848434200; Mon, 27 Jul 2020 04:13:54 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id i10sm8174705ild.29.2020.07.27.04.13.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 04:13:53 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 61EE9800188; Mon, 27 Jul 2020 06:13:52 -0500 (CDT) Date: Mon, 27 Jul 2020 06:13:52 -0500 From: Justin Pryzby To: Mahendra Singh Thalor Cc: pgsql-hackers@postgresql.org Subject: Re: display offset along with block number in vacuum errors Message-ID: <20200727111352.GN4286@telsasoft.com> References: 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 Fri, Jul 24, 2020 at 11:18:43PM +0530, Mahendra Singh Thalor wrote: > Hi hackers, > We discussed in another email thread[1], that it will be helpful if we can > display offset along with block number in vacuum error. Here, proposing a > patch to add offset along with block number in vacuum errors. Thanks. I happened to see both threads, only by chance. I'd already started writing the same as your 0001, which is essentially the same as yours. Here: @@ -1924,14 +1932,22 @@ lazy_vacuum_page(Relation onerel, BlockNumber blkno, Buffer buffer, BlockNumber tblk; OffsetNumber toff; ItemId itemid; + LVSavedErrInfo loc_saved_err_info; tblk = ItemPointerGetBlockNumber(&dead_tuples->itemptrs[tupindex]); if (tblk != blkno) break; /* past end of tuples for this block */ toff = ItemPointerGetOffsetNumber(&dead_tuples->itemptrs[tupindex]); + + /* Update error traceback information */ + update_vacuum_error_info(vacrelstats, &loc_saved_err_info, VACUUM_ERRCB_PHASE_VACUUM_HEAP, + blkno, toff); itemid = PageGetItemId(page, toff); ItemIdSetUnused(itemid); unused[uncnt++] = toff; + + /* Revert to the previous phase information for error traceback */ + restore_vacuum_error_info(vacrelstats, &loc_saved_err_info); } I'm not sure why you use restore_vacuum_error_info() at all. It's already called at the end of lazy_vacuum_page() (and others) to allow functions to clean up after their own state changes, rather than requiring callers to do it. I don't think you should use it in a loop, nor introduce another LVSavedErrInfo. Since phase and blkno are already set, I think you should just set vacrelstats->offnum = toff, rather than calling update_vacuum_error_info(). Similar to whats done in lazy_vacuum_heap(): tblk = ItemPointerGetBlockNumber(&vacrelstats->dead_tuples->itemptrs[tupindex]); vacrelstats->blkno = tblk; I think you should also do: @@ -2976,6 +2984,7 @@ heap_page_is_all_visible(Relation rel, Buffer buf, ItemId itemid; HeapTupleData tuple; + vacrelstats->offset = offnum; I'm not sure, but maybe you'd also want to do the same in more places: @@ -2024,6 +2030,7 @@ lazy_check_needs_freeze(Buffer buf, bool *hastup) @@ -2790,6 +2797,7 @@ count_nondeletable_pages(Relation onerel, LVRelStats *vacrelstats) -- Justin