From: | E-BLOKOS <admin(at)e-blokos(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Cannot pg_dump_all anymore... |
Date: | 2025-03-19 14:02:29 |
Message-ID: | d19f56a4-c6ae-435f-9e6e-a1cad0f78271@e-blokos.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2025-03-19 14:08:58 | Re: Cannot pg_dump_all anymore... |
Previous Message | Christoph Berg | 2025-03-19 12:02:54 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |