| 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: | Whole Thread | Raw Message | 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 |