Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGPTv-0007J6-Oy for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 14:54:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hGPTt-0000YB-Dl for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 14:54:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGPTs-0000Qp-Sd for pgsql-hackers@lists.postgresql.org; Tue, 16 Apr 2019 14:54:41 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGPTp-0006hL-SF for pgsql-hackers@postgresql.org; Tue, 16 Apr 2019 14:54:39 +0000 Received: by mail-qt1-x843.google.com with SMTP id v32so23560520qtc.10 for ; Tue, 16 Apr 2019 07:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=9lxJibvxAGOV5rmXdqN5jLt7cCNq9PhHjJ0SOnRjL0s=; b=b9WLcSkSQ0PyN7LQjaXLVvGe2xGU7OD+e16MH7Ss6tmXPevMVnPQbenwIkqYEljI0g Kbo9v7WJ64DM+FzklXs5OjGZI7g4HBh15oaC1Fn1UPIDKjj7TEcfcWV6hhDOsnDsQlkB /BKLimKB/umvZbNL4ItO5oJlG/278AXLeI+fOPQqqYWu3fpNvrTy276ER9Prp0L6dv35 mGSS49K0ZGp9ruDX82l0zvzIP9bYIfY/sYM47TYwwVrb3EyqhBc18whYb4viS9OSE5pD tfV/LOgnEUf0dn0ayenZl1aSsr/kampknAURDgipmEuHKPoFwTlZC0DnpO1SAcOjzpi/ KMxQ== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=9lxJibvxAGOV5rmXdqN5jLt7cCNq9PhHjJ0SOnRjL0s=; b=AP/FFg4itUWTxSSY9twSbOgBfimLMGJN0tPyQB3AvXqMKUcoXY5dRq5btmSuFVOp9B K5Wlf8Oo6ZQW8lXJUdqAaaiVK4idyrkr+FQ3WkfuEPTJHf6Cg6A5u3cWuBAu4olWeBzV MLvBoBMnCR9J1S9p2eH8ZQwdNC1vrgtPRCeOSbax6HEBiHJBg71Lau5nqoSRsq2S0uAo hctoDUlYo9P+8Od1SGmdWvNhog/LMEXRXGCETyFB3dQZ8q0lB25A16YTPbp5TwxxsHOW VlMx0POEqfVM/DIzp+nGhkz14Z0WJIcgXPjCbGbK2ZNpLvXj/dQuPmThL4VroP0g51Nd hEdA== X-Gm-Message-State: APjAAAWfiS/9vFef0XXM46jBfMIeuqaKPxIF7mlManjG9eZd+9pGR/Eo Tx8zCOQvpYSD/e7VIgvm8mcFVg== X-Google-Smtp-Source: APXvYqxu1Kq4Qh+vnZ91eR3S5txHtuGn8d0wqTIvsrRWZLFr48Ceib0HOPLVC429qPrUL6jUgLesyA== X-Received: by 2002:ac8:3957:: with SMTP id t23mr66147491qtb.331.1555426477089; Tue, 16 Apr 2019 07:54:37 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id c9sm30717688qkb.86.2019.04.16.07.54.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 07:54:36 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 86ADB1214FD; Tue, 16 Apr 2019 10:54:34 -0400 (-04) Date: Tue, 16 Apr 2019 10:54:34 -0400 From: Alvaro Herrera To: Robert Haas Cc: Tom Lane , Masahiko Sawada , Kyotaro HORIGUCHI , "Bossart, Nathan" , PostgreSQL-development Subject: Re: New vacuum option to do only freezing Message-ID: <20190416145434.GA23796@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 2019-Apr-16, Robert Haas wrote: > On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote: > > > I'm not sure that's correct. If you do that, it'll end up in the > > > non-tupgone case, which might try to freeze a tuple that should've > > > been removed. Or am I confused? > > > > If we're failing to remove it, and it's below the desired freeze > > horizon, then we'd darn well better freeze it instead, no? > > I don't know that that's safe. IIRC, the freeze code doesn't cope > nicely with being given a tuple that actually ought to have been > deleted. It'll just freeze it anyway, which is obviously bad. Umm, but if we fail to freeze it, we'll leave a tuple around that's below the relfrozenxid for the table, causing later pg_commit to be truncated and error messages saying that the tuple cannot be read, no? I remember that for a similar case in multixact-land, what we do is generate a fresh multixact that carries the members that are still alive (ie. those that cause the multixact to be kept rather than remove it), and relabel the tuple with that one. So the old multixact can be removed safely. Obviously we cannot do that for XIDs, but I do wonder what can possibly cause a tuple to be unfreezable yet the XID to be below the freeze horizon. Surely if the transaction is that old, we should have complained about it, and generated a freeze horizon that was even older? > Unless this has been changed since I last looked at it. I don't think so. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services