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 1k25YS-00014e-9B for pgsql-hackers@arkaria.postgresql.org; Sun, 02 Aug 2020 04:25:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k25YR-0006rC-1d for pgsql-hackers@arkaria.postgresql.org; Sun, 02 Aug 2020 04:24: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 1k25YQ-0006qX-NM for pgsql-hackers@lists.postgresql.org; Sun, 02 Aug 2020 04:24:58 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k25YM-0006mj-GP for pgsql-hackers@postgresql.org; Sun, 02 Aug 2020 04:24:57 +0000 Received: by mail-io1-xd33.google.com with SMTP id t15so26523516iob.3 for ; Sat, 01 Aug 2020 21:24: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=+OEHd8dk9sQvXqk7ybuGsQrfX27KoRWG/ytuzDNFOYA=; b=R81lhBR3d0fzc/RZ3XIXkbSBBcHzzzeFk5WytfO0xMqtA/yHlsx6xK/ZymV8676d+M PZtWbIyo/p3tcFmjK3AmvgrHlzZt5lUfWaO/HyuP381lV/2QdJNAVh4Ax4wxs54vpY8s BOJdY/OEcLXifTqluSGCDjKABxorit2FIiDJ3Mtu29H1ZyEtz8hcUPobDQ5QHXEQo7DT LS0s8r2WeoFvZnDd1AXuetZToMyY82IKD49yq9oqmKJBOTP4YFm0R6Z2SGKC6AkbMij9 a3J24Folrd8lG5XT1KHLgCqbqYHX2Ku+8nn5TYm5pydWRC1iUN4UZ19g6o2H4n7Or/ge eYJw== 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=+OEHd8dk9sQvXqk7ybuGsQrfX27KoRWG/ytuzDNFOYA=; b=fTl2sCI2SmvPGDaKOOFjJgORq/BjLWRx/1HnFQQKivS+TA4dWxN8YGMduEH4cjVtW8 FicyEeOr0mgM+Kl1WgZl3ys4NoM75RGJlMFVPK9UJ5MRvk/QZeQcdfSB8rAyqOx0wAgq kyTuF1tmPqCg6a7wR0adnKoNoxakWmwSkttsBgaII8HkLCIw6RPvC/033Tb8udbzb7nv Tl80V0h1sGJfBRUMXYW01IZpJLnxyrN+JKGx3NnF2lTCruxOVmn401LuiP4VyjfbWXwA AinFnTLdW8d2Yn7C3RIfjdyLjYXIFM4dENP0iThQZFrI5yXaalgmAmVQ+6qul0v1uThU w25g== X-Gm-Message-State: AOAM5329jhlcr7roqthDhMSbVmbXI3lj1cJnqARC+MMp+HtQmGVgo2cH WYek02H2Com5LGsjv6n0WihmOw== X-Google-Smtp-Source: ABdhPJyN6zWvPHIBu7x7qKa5BkkjWm/oMhRbpA46h5Q3YGW0lmP71gMu4O7VSWlH4ymLF30D4bHxzA== X-Received: by 2002:a6b:9354:: with SMTP id v81mr10882881iod.13.1596342292854; Sat, 01 Aug 2020 21:24:52 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id h1sm8311609iob.8.2020.08.01.21.24.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Aug 2020 21:24:52 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 3ED68800194; Sat, 1 Aug 2020 23:24:51 -0500 (CDT) Date: Sat, 1 Aug 2020 23:24:51 -0500 From: Justin Pryzby To: Masahiko Sawada Cc: Mahendra Singh Thalor , pgsql-hackers@postgresql.org, Amit Kapila , Andres Freund Subject: Re: display offset along with block number in vacuum errors Message-ID: <20200802042451.GJ20393@telsasoft.com> References: <20200727111352.GN4286@telsasoft.com> <20200731215514.GC20393@telsasoft.com> <20200801061721.GF20393@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 Sun, Aug 02, 2020 at 01:02:42PM +0900, Masahiko Sawada wrote: > Thank you for updating the patch! > > Here are my comments on v3 patch: > > @@ -2024,6 +2033,11 @@ lazy_check_needs_freeze(Buffer buf, bool *hastup) > if (PageIsNew(page) || PageIsEmpty(page)) > return false; > > + /* Update error traceback information */ > + update_vacuum_error_info(vacrelstats, &saved_err_info, > + VACUUM_ERRCB_PHASE_SCAN_HEAP, vacrelstats->blkno, > + InvalidOffsetNumber); > + > maxoff = PageGetMaxOffsetNumber(page); > for (offnum = FirstOffsetNumber; > offnum <= maxoff; > > You update the error callback phase to VACUUM_ERRCB_PHASE_SCAN_HEAP > but I think we're already in that phase. I'm okay with explicitly > setting it but on the other hand, we don't set the phase in > heap_page_is_all_visible(). Is there any reason for that? That part was my suggestion, so I can answer that. I added update_vacuum_error_info() to lazy_check_needs_freeze() to allow it to later call restore_vacuum_error_info(). > Also, since we don't reset vacrelstats->offnum at the end of > heap_page_is_all_visible(), if an error occurs by the end of > lazy_vacuum_page(), the caller of heap_page_is_all_visible(), we > report the error context with the last offset number in the page, > making the users confused. So it looks like heap_page_is_all_visible() should also call the update and restore functions. Do you agree with my suggestion that the VACUUM phase should never try to report an offset ? How do you think we can phrase the message to avoid confusion due to 0-based block number and 1-based offset ? Thanks, -- Justin