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 1ivvuc-0001Go-Rj for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jan 2020 04:22:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ivvub-0000qs-O0 for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jan 2020 04:22:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ivvub-0000ql-7c for pgsql-hackers@lists.postgresql.org; Mon, 27 Jan 2020 04:22:09 +0000 Received: from mail-pf1-x441.google.com ([2607:f8b0:4864:20::441]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ivvuY-0001G1-F8 for pgsql-hackers@postgresql.org; Mon, 27 Jan 2020 04:22:08 +0000 Received: by mail-pf1-x441.google.com with SMTP id 185so513167pfv.3 for ; Sun, 26 Jan 2020 20:22:05 -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:in-reply-to:user-agent; bh=GOsbwVp6aLhgpIDURifDTl9zO4Kz7P/leXjJXwbgj/s=; b=AjHgXkB68dwt7m/9Lsb1lenX5O10T0mgZcZplGShGjvFd7rlqjBpkoKIG7FIc5Caop JdCzA5mKC8hHIitaJoT3OJLJr37hqf1eOfYF5zZoh99ajjOzJ7NFhno3L+lnOsfJrEdY v/h7TF2m2q8aYMUcKNH7mZ+ySkORqZoj7qmGU= 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=GOsbwVp6aLhgpIDURifDTl9zO4Kz7P/leXjJXwbgj/s=; b=sAPQkdpBaW5ywFRT3PhUB0OmyKbzMGsAjQnO79pruzMI3YwleethQQ4H6SN6OzHBHn SZOuu5rwI9xozTs5mIeJWBrk/Vg88tenI/yVm6yPRaXCdampxgETeeNFAnfFcoKQqanL 4r25c4ev1eYKpZYpmmrRKAnuDJb0GqyjFBKiQtpKyE/n/QZfaVfKuO/ReY/I1+uswGjr deDz3QoRDEjRlqymBQrR1xOwhe7xpjEzsjB3fOIVSjlkntsqPltXD5SQbNHCZPV6Yr9z OR8CKKqlORkl7Kmo5x952XYvAJNlLMQ++vL2CoK5iLH5tbVqEY9qxr3H2cjoorwk/6T6 UKBQ== X-Gm-Message-State: APjAAAXhzduLdXeTphYAEIMOkY2mW/qqUSPoN9kz73Wsdg/rZLf9nyny YuA3WTTeM1UbfmC7GAX1Gi98wA== X-Google-Smtp-Source: APXvYqz5FQnkotyhbzLMyrAgpmb751K8A8e84brgPXs+EbJAhLe/YNhjZsH0+Ifqp5yk5pKmsw6rtg== X-Received: by 2002:aa7:8bcd:: with SMTP id s13mr7994649pfd.234.1580098924064; Sun, 26 Jan 2020 20:22:04 -0800 (PST) Received: from rfd.leadboat.com (108-233-125-46.lightspeed.sntcca.sbcglobal.net. [108.233.125.46]) by smtp.gmail.com with ESMTPSA id t138sm2696810pfc.95.2020.01.26.20.22.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jan 2020 20:22:03 -0800 (PST) Date: Sun, 26 Jan 2020 20:22:01 -0800 From: Noah Misch To: Kyotaro Horiguchi Cc: robertmhaas@gmail.com, pgsql-hackers@postgresql.org, 9erthalion6@gmail.com, andrew.dunstan@2ndquadrant.com, hlinnaka@iki.fi, michael@paquier.xyz Subject: Re: [HACKERS] WAL logging problem in 9.4.3? Message-ID: <20200127042201.GA3119606@rfd.leadboat.com> References: <20200115.171857.1170166613760719188.horikyota.ntt@gmail.com> <20200116.142057.1250623796779593147.horikyota.ntt@gmail.com> <20200119035139.GA2811524@rfd.leadboat.com> <20200121.184557.1462314355964996736.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200121.184557.1462314355964996736.horikyota.ntt@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Diffing the two latest versions of one patch: > --- v32-0002-Fix-the-defect-1.patch 2020-01-18 14:32:47.499129940 -0800 > +++ v33-0002-Fix-the-defect-1.patch 2020-01-26 16:23:52.846391035 -0800 > +@@ -2978,8 +3054,8 @@ AssertPendingSyncs_RelationCache(void) > + LOCKTAG_RELATION) > + continue; > + relid = ObjectIdGetDatum(locallock->tag.lock.locktag_field2); > +- r = RelationIdGetRelation(relid); > +- if (r == NULL) > ++ r = RelationIdGetRelationCache(relid); The purpose of this loop is to create relcache entries for rels locked in the current transaction. (The "r == NULL" case happens for rels no longer visible in catalogs. It is harmless.) Since RelationIdGetRelationCache() never creates a relcache entry, calling it defeats that purpose. RelationIdGetRelation() is the right function to call. On Tue, Jan 21, 2020 at 06:45:57PM +0900, Kyotaro Horiguchi wrote: > Three other fixes not mentined above are made. One is the useless > rd_firstRelfilenodeSubid in the condition to dicide whether to > preserve or not a relcache entry It was not useless. Test case: create table t (c int); begin; alter table t alter c type bigint; -- sets rd_firstRelfilenodeSubid savepoint q; drop table t; rollback to q; -- forgets rd_firstRelfilenodeSubid commit; -- assertion failure, after s/RelationIdGetRelationCache/RelationIdGetRelation/ discussed above