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 1k1czr-0000Zk-GF for pgsql-hackers@arkaria.postgresql.org; Fri, 31 Jul 2020 21:55:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k1czq-0007PB-B2 for pgsql-hackers@arkaria.postgresql.org; Fri, 31 Jul 2020 21:55:22 +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 1k1czp-0007P3-N0 for pgsql-hackers@lists.postgresql.org; Fri, 31 Jul 2020 21:55:21 +0000 Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k1czl-00009f-Kk for pgsql-hackers@postgresql.org; Fri, 31 Jul 2020 21:55:19 +0000 Received: by mail-io1-xd43.google.com with SMTP id d18so33115569ion.0 for ; Fri, 31 Jul 2020 14:55:17 -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=GG0V/kxmkVIWAT8KXgkHzF+Cx7uo51RjpqkwA6bPfR8=; b=m8/k9+0+k6bpzxLKVnCHGS+Zp/cvalxT+HKKQBl7ZM80683IZJwVKotRdRW7pNwykF UKNqlHQ9ywqpE8tnBbk9EIfAJC31U8cz523D/0Z/r5ji+q7+lJlNISnnp5riYwsTu5dq wn2Y2izsGpWW7iSTvGCDG+6Amjk/DOXWUgZAb8SooTwQueXmHy1/2wbAXxpGIncQuD1O +gG1ZM6y6IQKKJyH6XRuhH2vPWYMsDttjEc7eMj1t6YPP3LLIEY/AlVxioVYfgfJsO1i nduSdtcS2KEtbQucjzWks5dcCXhh8E5owZHFsQ4/Kuhpxw+bb7VPiWoVhpY5WmEi2Ko+ BnRg== 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=GG0V/kxmkVIWAT8KXgkHzF+Cx7uo51RjpqkwA6bPfR8=; b=LZ3Lqd+q5MysjlXkdkOOcCVuxGNvKRmHSZqvwQf25w5gRO/baPR4ERPPsEyNXI5Vh2 D5msLyYgu6ehYftMIvU9o3QUYuO/wLeRKQQ6qYoTFf11Lvn7myz2RzeCEd2BIySxbjgN HwKZECp6sKvkyQFlZYa7THiLcrIR3yQqM23ygsVfo6XJiFQJgB/sjNG9/pl8PDl0dSHq M7jULMjPNqOgS4ERr7zd267ejvuACWUx2nZSC2BH6VpOp9KB+NAMn6pRIEDQk4h/+k9E nWPzjhOFZTkzBdHXmkL4b53rU5Uj5ynhyuvI0BAIUI/rP/X80a8D9A9Wba6QKq5tstgp vtmw== X-Gm-Message-State: AOAM5315CkmLsGu6uh1DWDZmaf5lT/eCvX1sHY0h+KcBa1TtDSc0XAfB stuL5N9KlN5pAJ+JqmddaB6hsQ== X-Google-Smtp-Source: ABdhPJwpL/ABZtMfO1zKmLoRRzQ0UifO5JyaP+QI+juEKAUhRLFUijLLB+EnmnUOhH0+xvCiE61YdQ== X-Received: by 2002:a6b:e517:: with SMTP id y23mr5534943ioc.190.1596232516955; Fri, 31 Jul 2020 14:55:16 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id e84sm5676598ill.60.2020.07.31.14.55.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 14:55:16 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id F20A2800190; Fri, 31 Jul 2020 16:55:14 -0500 (CDT) Date: Fri, 31 Jul 2020 16:55:14 -0500 From: Justin Pryzby To: Mahendra Singh Thalor Cc: pgsql-hackers@postgresql.org, Masahiko Sawada Subject: Re: display offset along with block number in vacuum errors Message-ID: <20200731215514.GC20393@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 Bcc: Subject: Re: display offset along with block number in vacuum errors Reply-To: In-Reply-To: On Wed, Jul 29, 2020 at 12:35:17AM +0530, Mahendra Singh Thalor wrote: > > 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; > > Fixed. I rearead this thread and I think the earlier suggestion from Masahiko was right. The loop around dead_tuples only does ItemIdSetUnused() which updates the page, which has already been read from disk. On my suggestion, your v2 patch sets offnum directly, but now I think it's not useful to set at all, since the whole page is manipulated by PageRepairFragmentation() and log_heap_clean(). An error there would misleadingly say "..at offset number MM", but would always show the page's last offset, and not the offset where an error occured. I added this at: https://commitfest.postgresql.org/29/2662/ If anyone is considering this patch for v13, I guess it should be completed by next week. -- Justin