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 1o5WpQ-0000KF-J0 for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Jun 2022 18:17:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o5WpP-0004N4-AO for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Jun 2022 18:17:47 +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 1o5WpO-0004Mu-AN for pgsql-hackers@lists.postgresql.org; Sun, 26 Jun 2022 18:17:47 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o5WpE-0005ha-BJ for pgsql-hackers@lists.postgresql.org; Sun, 26 Jun 2022 18:17:43 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B1CCF5C0154; Sun, 26 Jun 2022 14:17:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 26 Jun 2022 14:17:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1656267452; x=1656353852; bh=P xpwz5mhFXt1brPOev0mwUc3P0mHUQwpKzlxnDXIgQw=; b=ACu6XlweogJI5+7Ls sjRuhCyv4D2GiwajshB3tZrMar3LPLiRTVV2B3oXdesjAEPVkjxeeiXc9GooIltd Xovktw1Fl1nuEZvUehBcEyPtZePHb/XBvmuKogEimqjc1l1PRNlR/izyNEh/kvLU XVFf5S58an6Pihodm35wsLjJ4Sre2t9sQ030v17IaH5Br/erYFBIUTo/OelawmJK YffblEw5Xr2q3Fs6BMBnpV88jh1CPuiluD5uW208bTgrrOKITENtz7j2Ud84Y2H6 15zxwefuv2XHBP2Po7oDPhb3YOM+80MfzaayOy7Irsfu3reMcSKwsF/H/Zx4XpdH 5zVQA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegfedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpefhueehueeugfffleehhffhledtueevhfdvjedvkeel teeltddtgedtvedtveekkeenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmpdhlfihnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 Jun 2022 14:17:31 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 4E60035D; Sun, 26 Jun 2022 19:50:27 +0200 (CEST) Date: Sun, 26 Jun 2022 19:50:27 +0200 From: Alvaro Herrera To: vignesh C Cc: "houzj.fnst@fujitsu.com" , Amit Kapila , Masahiko Sawada , Japin Li , Dilip Kumar , rajesh singarapu , PostgreSQL Hackers , Zheng Li Subject: Re: Support logical replication of DDLs Message-ID: <20220626175027.7glhsnfwfbo2pyxt@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jun-22, vignesh C wrote: > 1) Creation of temporary table fails infinitely in the subscriber. > CREATE TEMPORARY TABLE temp1 (a int primary key); > > The above statement is converted to the below format: > CREATE TEMPORARY TABLE pg_temp.temp1 (a pg_catalog.int4 , > CONSTRAINT temp1_pkey PRIMARY KEY (a)); > While handling the creation of temporary table in the worker, the > worker fails continuously with the following error: > 2022-06-22 14:24:01.317 IST [240872] ERROR: schema "pg_temp" does not exist Perhaps one possible fix is to change the JSON format string used in deparse_CreateStmt. Currently, the following is used: + if (node->ofTypename) + fmtstr = "CREATE %{persistence}s TABLE %{if_not_exists}s %{identity}D " + "OF %{of_type}T %{table_elements}s " + "%{with_clause}s %{on_commit}s %{tablespace}s"; + else + fmtstr = "CREATE %{persistence}s TABLE %{if_not_exists}s %{identity}D " + "(%{table_elements:, }s) %{inherits}s " + "%{with_clause}s %{on_commit}s %{tablespace}s"; + + createStmt = + new_objtree_VA(fmtstr, 1, + "persistence", ObjTypeString, + get_persistence_str(relation->rd_rel->relpersistence)); (Note that the word for the "persistence" element here comes straight from relation->rd_rel->relpersistence.) Maybe it would be more appropriate to set the schema to empty when the table is temp, since the temporary-ness is in the %{persistence} element, and thus there is no need to schema-qualify the table name. However, that would still replicate a command that involves a temporary table, which perhaps should not be considered fit for replication. So another school of thought is that if the %{persistence} is set to TEMPORARY, then it would be better to skip replicating the command altogether. I'm not sure how to plug that in the replication layer, however. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "At least to kernel hackers, who really are human, despite occasional rumors to the contrary" (LWN.net)