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 1maQgj-0003RG-7M for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Oct 2021 22:56:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1maQgi-0005vk-6V for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Oct 2021 22:56:00 +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 1maQgh-0005vc-Nt for pgsql-hackers@lists.postgresql.org; Tue, 12 Oct 2021 22:55:59 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1maQgf-0007qr-1t for pgsql-hackers@lists.postgresql.org; Tue, 12 Oct 2021 22:55:59 +0000 Received: by mail-pl1-x634.google.com with SMTP id g5so537567plg.1 for ; Tue, 12 Oct 2021 15:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ardentperf-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=pv3fMnWKHncetoyoQZ+ERY1aUE78pIfVq299WQOLulQ=; b=upBXTSB6o/Fhy2sOWSJOntQKZjjR6yZBRii+jbhUsHOBrUv8R6NSKLW7YQiwjKwrcK c0CKrMTQPbwGXepTxwXB8ZGMAXW8Mqcukx4kFoNIqj8YZjwVq9NcL8gPCfgRZT7KiV4R 6g1eLDUCYIffjLT5AcVjpihG7GLfZ4mdWmynn8FIJewhRiAj2b+gteb4OjBigKyJVZRL uWQpBCpO6S0SZTQlk76bdvetS2veD6ES91AzHoOfr0eXXfW/QaHbwG+i6A4hIoZ5uleW XfGADUH6GOPaMKvxHJiAjAW6eJ/FMwVo6eQOA8ORIOcfaaixXPTzG3PzBODAkDSNa0ym +SGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=pv3fMnWKHncetoyoQZ+ERY1aUE78pIfVq299WQOLulQ=; b=ntlnEAAk4Jjw7b/bnBiQ1rXrhRkz61hlvI7KjV+kNvdxdT31XRajsZYRTzT/LqUkrF pl4ZAdJVPtp429SMPT5wdWqV90kh3WrhrqlBcmQD0zsqsZaEcFwPRW7h9QqRmtw61Fu2 xX87Fg7GhXuuoiOm7zgq3ANJzVIkT2M1/VfJjKVLmIa3oydE3JZLizU/h1fC7D+W0lPA 6u8tqIkSKLveZtmrnTHRjF0SGMnAWB/iR+3ublYYsxSrxxw391Hm60FRGAnVZRXndXcN eTAtKvmIHrxLYOVrmdT8BA/Oj71Ves84By1SSo+tO9tsO17mtDDaWIIFVCUdpP8Uqw1C 5OzA== X-Gm-Message-State: AOAM53088nnEhQFaAvEuDsBMLixEVHFmxyCvIny2bd8Fg3JZSP+I8jTE 9dUMGkzikTDhGvrxPEh04yG1aQ== X-Google-Smtp-Source: ABdhPJz6dUQz05KCzKmOVEWAEE3H9AoyqNpkExdnnCfo8wL6ASZ/+elkYEdsz3B1cgSrZdjypYMaug== X-Received: by 2002:a17:90b:388a:: with SMTP id mu10mr9458531pjb.0.1634079354443; Tue, 12 Oct 2021 15:55:54 -0700 (PDT) Received: from [10.111.232.31] (54-240-196-185.amazon.com. [54.240.196.185]) by smtp.gmail.com with ESMTPSA id q8sm3791099pja.52.2021.10.12.15.55.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Oct 2021 15:55:54 -0700 (PDT) Message-ID: Date: Tue, 12 Oct 2021 15:55:53 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns Content-Language: en-US To: Masahiko Sawada , Kyotaro Horiguchi Cc: "Drouvot, Bertrand" , PostgreSQL Hackers , "Oh, Mike" References: <6a176936-1af1-41d9-9ded-bde0eb47dd5c@amazon.com> <20211008.165055.1621145185927268721.horikyota.ntt@gmail.com> From: Jeremy Schneider In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 10/10/21 23:27, Masahiko Sawada wrote: > > After more thought, given DDLs are not likely to happen than DML in > practice, ... I haven't looked closely at the patch, but I'd be careful about workloads where people create and drop "temporary tables". I've seen this pattern used a few times, especially by developers who came from a SQL server background, for some reason. I certainly don't think we need to optimize for this workload - which is not a best practice on PostreSQL. I'd just want to be careful not to make PostgreSQL logical replication crumble underneath it, if PG was previously keeping up with difficulty. That would be a sad upgrade experience! -Jeremy -- http://about.me/jeremy_schneider