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 1kyMWY-0007Ry-CO for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Jan 2021 22:15:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kyMWV-0004lV-9n for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Jan 2021 22:15:51 +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 1kyMWU-0004lO-Rl for pgsql-hackers@lists.postgresql.org; Sat, 09 Jan 2021 22:15:51 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kyMWP-00079e-Ew for pgsql-hackers@postgresql.org; Sat, 09 Jan 2021 22:15:49 +0000 Received: by mail-pl1-x62f.google.com with SMTP id 4so7528803plk.5 for ; Sat, 09 Jan 2021 14:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=qDHIU3N7JsbXH3IsU7kKW80an3W420XbDff/PNn19Rg=; b=I9Y3Rdn6wgkM2+q8kMORHF8E6WHGuJckpsSvQ3tq9KlFgY/Z0HVsDJ5bHk+RYRS9ji /kZp1uqNfVUBxYRVXJH2//DruPlnO6IQYpo1dpmoCDxMjyDVINc0ne4fLXlOnL612rx5 aReUMUiYrIdKkTrNob7ND6MzFacr9JZFYiCZ0= 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:content-transfer-encoding :in-reply-to:user-agent; bh=qDHIU3N7JsbXH3IsU7kKW80an3W420XbDff/PNn19Rg=; b=TI/2HZKBGIP2UaNX10UKp7ZzftkdVCfu6LFbx16k7QIKYKMvUXunLC5C4ZrHxaDr71 bxjKLnMYZdhC/7R21mF5xDizOhd6i+kC9HL+Q3AzejpIVg7esZLSqdbLMpYWY3RCDn38 uTRBm6pVpM5alE34S+jav4G93ZxR9txi8XwKH4iON0q7T6O1CCG9nmXPbnEJRGu/2PO7 m4OQUBeotprFF+d/mGap1Kb5lZCM1kBi7VvCvq1P2zgNtKhgdbeJCbrdzJ5zoevlhlew k4Gp30IdyUYL5y8sDiNXlGOXKL/lf32g8ddmQc7UjMPjrSjNGbP5HxtMqB9N979+UW41 Hf6w== X-Gm-Message-State: AOAM532p/0EPClSG/n2vQ8pVtoB+gLTPbYCSFg2pwi9Jl5WMt5Hv/XmD TS0IZDfGrw+Tf8jipRNHdHjJsw== X-Google-Smtp-Source: ABdhPJy55sxFwkli1uDvAZo1OAeMD95a4mdSjvFwXVzQbOz99J4g+eVJ0cpHdUj6N/NeDxFyKxCzqw== X-Received: by 2002:a17:902:e901:b029:db:c0d6:62cc with SMTP id k1-20020a170902e901b02900dbc0d662ccmr9950676pld.7.1610230543089; Sat, 09 Jan 2021 14:15:43 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id s1sm12403076pfb.103.2021.01.09.14.15.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jan 2021 14:15:42 -0800 (PST) Date: Sat, 9 Jan 2021 14:15:39 -0800 From: Noah Misch To: Andrey Borodin Cc: Tom Lane , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding Message-ID: <20210109221539.GA179375@rfd.leadboat.com> References: <1959.1586198769@sss.pgh.pa.us> <20200407041847.GA519993@rfd.leadboat.com> <20200525070033.GA1591335@rfd.leadboat.com> <20200830053433.GA3275593@rfd.leadboat.com> <20201029040159.GA3803708@rfd.leadboat.com> <20201109045319.GA459206@rfd.leadboat.com> <23599722-1EFF-4B71-A77C-67141882EFAE@yandex-team.ru> <561A2AF4-E745-4043-B5FC-9537AEE55701@yandex-team.ru> <20210109101759.GA122398@rfd.leadboat.com> <0B9F7E26-2C0F-43E7-A0C5-FB84DA1163DB@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0B9F7E26-2C0F-43E7-A0C5-FB84DA1163DB@yandex-team.ru> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Jan 09, 2021 at 08:25:39PM +0500, Andrey Borodin wrote: > > 9 янв. 2021 г., в 15:17, Noah Misch написал(а): > >> I'm a little bit afraid that this kind of patch can hide bugs (while potentially saving some users data). Besides this patch seems like a useful precaution. Maybe we could emit scary warnings if SLRU segments do not stack into continuous range? > > > > Scary warnings are good for an observation that implies a bug, but the > > slru-truncate-t-insurance patch causes such an outcome in non-bug cases where > > it doesn't happen today. In other words, discontinuous ranges of SLRU > > segments would be even more common after that patch. For example, it would > > happen anytime oldestXID advances by more than ~1B at a time. > > Uhm, I thought that if there is going to be more than ~1B xids - we are going to keep all segements forever and range still will be continuous. Or am I missing something? No; it deletes the most recent ~1B and leaves the older segments. An exception is multixact, as described in the commit message and the patch's change to a comment in TruncateMultiXact().