Cannot pg_dump_all anymore...

Started by E-BLOKOSabout 1 year ago8 messagesgeneral
Jump to latest
#1E-BLOKOS
infos@e-blokos.com

I got this error:

pg_dump: error: query returned 0 rows instead of one: EXECUTE
dumpBaseType('794978')

any clue to solve it?

thanks

David

#2Ron
ronljohnsonjr@gmail.com
In reply to: E-BLOKOS (#1)
Re: Cannot pg_dump_all anymore...

On Tue, Mar 18, 2025 at 5:14 AM E-BLOKOS <infos@e-blokos.com> wrote:

I got this error:

pg_dump: error: query returned 0 rows instead of one: EXECUTE
dumpBaseType('794978')

any clue to solve it?

PG version?

Whole command line, including all error messages?

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

#3Greg Sabino Mullane
greg@turnstep.com
In reply to: E-BLOKOS (#1)
Re: Cannot pg_dump_all anymore...

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

#4E-BLOKOS
infos@e-blokos.com
In reply to: Greg Sabino Mullane (#3)
Re: Cannot pg_dump_all anymore...

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

#5E-BLOKOS
infos@e-blokos.com
In reply to: Ron (#2)
Re: Cannot pg_dump_all anymore...

On 3/18/2025 3:59 AM, Ron Johnson wrote:

On Tue, Mar 18, 2025 at 5:14 AM E-BLOKOS <infos@e-blokos.com> wrote:

I got this error:

pg_dump: error: query returned 0 rows instead of one: EXECUTE
dumpBaseType('794978')

any clue to solve it?

PG version?

PG 17.4

Whole command line, including all error messages?

setpriv su - postgres -c "pg_dumpall --no-comments -h /run/postgresql -p
5432 > out.sql"

--
E-BLOKOS

#6Support
admin@e-blokos.com
In reply to: Greg Sabino Mullane (#3)
Re: Cannot pg_dump_all anymore...

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

#7Greg Sabino Mullane
greg@turnstep.com
In reply to: Support (#6)
Re: Cannot pg_dump_all anymore...

On Wed, Mar 19, 2025 at 10:02 AM E-BLOKOS <admin@e-blokos.com> wrote:

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

More likely to be a problem with pg_repack. Please tell us the exact
versions of pg_repack and Postgres in use here.

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

#8Support
admin@e-blokos.com
In reply to: Greg Sabino Mullane (#7)
Re: Cannot pg_dump_all anymore...

Hi,

On 3/19/2025 7:08 AM, Greg Sabino Mullane wrote:

On Wed, Mar 19, 2025 at 10:02 AM E-BLOKOS <admin@e-blokos.com> wrote:

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

More likely to be a problem with pg_repack.  Please tell us the exact
versions of pg_repack and Postgres in use here.

PG 17.4

pg_repack last git

thanks

David

--
E-BLOKOS