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 1tuu0G-00DgR4-1i for pgsql-general@arkaria.postgresql.org; Wed, 19 Mar 2025 14:02:40 +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 1tuu0D-005D1W-Vo for pgsql-general@arkaria.postgresql.org; Wed, 19 Mar 2025 14:02:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tuu0D-005D0U-KU for pgsql-general@lists.postgresql.org; Wed, 19 Mar 2025 14:02:37 +0000 Received: from [2001:bc8:1203:362::1] (helo=ns117.e-blokos.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tuu08-003ljt-0w for pgsql-general@lists.postgresql.org; Wed, 19 Mar 2025 14:02:35 +0000 Received: from [127.0.0.1] (ip6-localhost [127.0.0.1]) by mail.e-blokos.com (8.18.1/8.18.1) with ESMTP id 52JE2UcK042999 for ; Wed, 19 Mar 2025 14:02:31 GMT Content-Type: multipart/alternative; boundary="------------s050NcO2RZFj0cLkbtw095Hf" Message-ID: Date: Wed, 19 Mar 2025 07:02:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cannot pg_dump_all anymore... Content-Language: en-US To: pgsql-general@lists.postgresql.org References: <92435272-360f-48fa-8ca0-a4ea89359c80@e-blokos.com> From: E-BLOKOS In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:bc8:1203:362::1 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------s050NcO2RZFj0cLkbtw095Hf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/18/2025 5:49 AM, Greg Sabino Mullane wrote: > First figure out which database is having that issue, by using pg_dump > --schema-only on each database in turn. Then run this SQL on the > database giving the error to see if the type exists, or what is nearby: > > select oid, typname, typtype, typnamespace::regnamespace from pg_type > where oid <= 794978 order by 1 desc limit 3; > > Also let us know the version of pg_dump and the version of Postgres > being dumped. > > > Cheers, > Greg > > -- > Crunchy Data - https://www.crunchydata.com > Enterprise Postgres Software Products & Tech Support > ok I fixed it with: SELECT * FROM pg_depend WHERE objid IN (794964, 794968); DELETE FROM pg_depend WHERE objid IN (794964, 794968); systemctl restart postgresql is it possible a crash happened with a VACUUM and a machine reboot in same time? -- E-BLOKOS --------------s050NcO2RZFj0cLkbtw095Hf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 3/18/2025 5:49 AM, Greg Sabino Mullane wrote:
First figure out which database is having that issue, by using pg_dump --schema-only on each database in turn. Then run this SQL on the database giving the error to see if the type exists, or what is nearby:

select oid, typname, typtype, typnamespace::regnamespace from pg_type where oid <= 794978 order by 1 desc limit 3;

Also let us know the version of pg_dump and the version of Postgres being dumped.


Cheers,
Greg

--
Enterprise Postgres Software Products & Tech Support

ok I fixed it with:

SELECT * FROM pg_depend WHERE objid IN (794964, 794968);
DELETE FROM pg_depend WHERE objid IN (794964, 794968);

systemctl restart postgresql

is it possible a crash happened with a VACUUM and a machine reboot in same time?

-- 
E-BLOKOS
--------------s050NcO2RZFj0cLkbtw095Hf--