| From: | E-BLOKOS <infos(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 02:16:23 |
| Message-ID: | 35dafa40-372e-4fd8-bc52-d83833cafc81@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
>
select oid, typname, typtype, typnamespace::regnamespace from pg_type
where oid <= 794978 order by 1 desc limit 3;
oid | typname | typtype | typnamespace
--------+------------+---------+--------------
794970 | log_17167 | c | repack
794969 | _log_17167 | b | repack
794966 | pk_17167 | c | repack
(3 rows)
Arggh it's repack 🙁
I have no clue how to repair repack....
--
E-BLOKOS
| From | Date | Subject | |
|---|---|---|---|
| Next Message | E-BLOKOS | 2025-03-19 02:17:22 | Re: Cannot pg_dump_all anymore... |
| Previous Message | Nathan Bossart | 2025-03-19 01:42:45 | Re: Disabling vacuum truncate for autovacuum |