Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tLOxO-00EZGy-7R for pgsql-bugs@arkaria.postgresql.org; Wed, 11 Dec 2024 15:48:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tLOxK-00HH13-89 for pgsql-bugs@arkaria.postgresql.org; Wed, 11 Dec 2024 15:48:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tLOxJ-00HH0u-Vg for pgsql-bugs@lists.postgresql.org; Wed, 11 Dec 2024 15:48:55 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tLOxI-002HV0-Mm for pgsql-bugs@lists.postgresql.org; Wed, 11 Dec 2024 15:48:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4BBFmnOw482447; Wed, 11 Dec 2024 10:48:49 -0500 From: Tom Lane To: Artur Zakirov cc: Peter Eisentraut , PostgreSQL mailing lists Subject: Re: pg_dump crash on identity sequence with not loaded attributes In-reply-to: References: <4137493.1733781111@sss.pgh.pa.us> <66804.1733844592@sss.pgh.pa.us> <84249.1733854089@sss.pgh.pa.us> <191373.1733865316@sss.pgh.pa.us> Comments: In-reply-to Artur Zakirov message dated "Wed, 11 Dec 2024 12:38:59 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <482445.1733932129.1@sss.pgh.pa.us> Date: Wed, 11 Dec 2024 10:48:49 -0500 Message-ID: <482446.1733932129@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Artur Zakirov writes: > On Tue, 10 Dec 2024 at 22:15, Tom Lane wrote: >> The attached patch also gets rid of the dubious coding in >> getPublicationNamespaces. We might get push-back on that ignoring >> schemas belonging to extensions, but if so I'd prefer to see the >> behavior coded in a more transparent fashion. > But other than that it seems the patch breaks dumps of mapping of a > publication with the public namespace. The issue with the public > namespace is mentioned in the original thread of the feature of adding > schema mapping [1]. I couldn't find in the thread if it was addressed > in the end. With the new patch the following mapping won't be mapped: > create publication pub_test for tables in schema public; Ouch. Okay, I agree that's probably bad, but then it raises the question of why this filter exists at all. It certainly seems 100% magic and undocumented that it does the "right" thing for these cases. In any case, that's mostly orthogonal to the problem with identity sequences. I now propose leaving out that change and just pushing the change in getOwnedSeqs(). The publication-namespace business should be discussed on its own thread. regards, tom lane