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 1k0VRh-0004ug-Ok for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Jul 2020 19:39:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k0VRg-0008MS-Lu for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Jul 2020 19:39:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0VRg-0008ML-CH for pgsql-hackers@lists.postgresql.org; Tue, 28 Jul 2020 19:39:28 +0000 Received: from mail-io1-xd2e.google.com ([2607:f8b0:4864:20::d2e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k0VRd-0004pS-6T for pgsql-hackers@postgresql.org; Tue, 28 Jul 2020 19:39:27 +0000 Received: by mail-io1-xd2e.google.com with SMTP id q75so13874054iod.1 for ; Tue, 28 Jul 2020 12:39:24 -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=+2M67UbmzDhZoUcZf4gmsTN2MNiHJFr6zySYLaMMpSk=; b=ErgV+J4C3McXOyjsXsAiJdGzogtidSnwm3pMXaei97szlftk8P9FUDLh9D86ISx3l2 lML0eU7/QOdM5KpnPhk/OVpI2kLBv2htk/QZN5LjgtuE98Vu1g0f79CE6sVytYsDdDgW xwMK3R7VkviE3ktJfvLIP3DNz6kvP4c9r/xT5C9Z21rQBEC0biHs5JzsZKPdYIm0NLLr dz9qp4gJ2iGKyHaw63UeEYRy0m97ldnub2GgwD9eQvIV25VotFUiByy9TL1mSudHisUh yWy13o/w+za4savNKf0TARcRFZszRdV3pqXCbb3YtN9ir9WejkJrfYgRBaCCt9BwDCJ8 j8Rw== 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=+2M67UbmzDhZoUcZf4gmsTN2MNiHJFr6zySYLaMMpSk=; b=D3ZcOjGEMWGEpr0gRZfsYeMmP+hHSBhBBMjpQM7KuYPzfASYKm0Q/Eze77P5KctDfl +Yt1BIrfG1Iyniv3KIK3n42/HItwrQzg8IkjeQI+vNpOfW1dufZPsP2Q/SG+S79tma6O CzqqKZ9o/E0Znz9owVMnA8rsuPYohJcN751goRGj4+o31g0XuqN0wTCTWUsApDjVbzhH DCqHZjcQxScdWONJmYwVixE6cR3EGkY6N3pLntTiKRORW9IcvJCRfM3Kf+XxG8mJloQN QESkpTIzo1wevZAEtRqzeKkFeAVw4ab0PYNdkDAQUvs21mr7xw+frxy57tTZ8TB65kjP yniQ== X-Gm-Message-State: AOAM533izAehpqNCu3iU9nE1PUL7ym6XiRhc5SxCkDuoUva3t1nIAfA2 ZY81QTOIzViNhaPaHKa052ospg== X-Google-Smtp-Source: ABdhPJzKj98WnI1L65ly1Vx2Cl0pmGK5xXjIO/0wnM3FxgpMZnJ/tyYbZGWm0TCu9PdWdMYdwon+sA== X-Received: by 2002:a05:6638:138a:: with SMTP id w10mr18236806jad.36.1595965163155; Tue, 28 Jul 2020 12:39:23 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id e1sm10513915ilr.23.2020.07.28.12.39.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 12:39:22 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id F2D5C800182; Tue, 28 Jul 2020 14:39:19 -0500 (CDT) Date: Tue, 28 Jul 2020 14:39:19 -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: <20200728193919.GK20393@telsasoft.com> References: <20200727111352.GN4286@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 Wed, Jul 29, 2020 at 12:35:17AM +0530, Mahendra Singh Thalor wrote: > Apart from these, I fixed comments given by Sawada and Michael in the > latest patch. Attaching v2 patch for review. Thanks. lazy_check_needs_freeze iterates over blocks and this patch changes it to update vacrelstats. I think it should do what lazy_{vacuum/cleanup}_heap/page/index do and call update_vacuum_error_info() at its beginning (even though only the offset is changed), and then restore_vacuum_error_info() at its end (to "revert back" to the item number it started with). The same is true of heap_page_is_all_visible(), except it's only called by lazy_vacuum_page(), which already calls restore_vacuum_error_info() a few lines later. As for the message: + if (OffsetNumberIsValid(errinfo->offnum)) + errcontext("while scanning block %u and offset %u of relation \"%s.%s\"", + errinfo->blkno, errinfo->offnum, errinfo->relnamespace, errinfo->relname); + else + errcontext("while scanning block %u of relation \"%s.%s\"", + errinfo->blkno, errinfo->relnamespace, errinfo->relname); I think that may be confusing. A DBA should know what a "block" is, but "offset" sounds like a byte offset, rather than an item number. Here's what I'd written. Maybe it should say "offset number". + errcontext("while vacuuming block %u of relation \"%s.%s\", item offset %u", -- Justin