Thread: BUG #17394: pg_dump: query returned 0 rows instead of one:

The following bug has been logged on the website:

Bug reference:      17394
Logged by:          Surya Prakash
Email address:      suryasp1010@gmail.com
PostgreSQL version: 11.13
Operating system:   Windows server 2019
Description:

pg_dump: saving database definition
pg_dump: query returned 0 rows instead of one: 
SELECT proretset, prosrc, probin, pg_catalog.pg_get_function_arguments(oid)
AS funcargs,pg_catalog.pg_get_function_identity_arguments(oid) AS funciargs,
pg_catalog.pg_get_function_result(oid) AS funcresult,
array_to_string(protrftypes, ' ') AS protrftypes, prokind, provolatile,
proisstrict, prosecdef, proleakproof, proconfig, procost, prorows,
proparallel, (SELECT lanname FROM pg_catalog.pg_language WHERE oid =
prolang) AS lanname FROM pg_catalog.pg_proc WHERE oid =
'1046460'::pg_catalog.oid


I am getting this above error while taking backup of a database.

Hi,

On Thu, Feb 03, 2022 at 09:40:07PM +0000, PG Bug reporting form wrote:
> 
> pg_dump: saving database definition
> pg_dump: query returned 0 rows instead of one: 
> SELECT proretset, prosrc, probin, pg_catalog.pg_get_function_arguments(oid)
> AS funcargs,pg_catalog.pg_get_function_identity_arguments(oid) AS funciargs,
> pg_catalog.pg_get_function_result(oid) AS funcresult,
> array_to_string(protrftypes, ' ') AS protrftypes, prokind, provolatile,
> proisstrict, prosecdef, proleakproof, proconfig, procost, prorows,
> proparallel, (SELECT lanname FROM pg_catalog.pg_language WHERE oid =
> prolang) AS lanname FROM pg_catalog.pg_proc WHERE oid =
> '1046460'::pg_catalog.oid
> 
> 
> I am getting this above error while taking backup of a database.

Is the problem reproducible?

Can you try to execute the query on the target database, before and after
executing those queries:

SET enable_indexscan = off;
SET enable_indexonlyscan = off;
SET enable_bitmapscan = off;

If you the query returns a result after the 3 SET enable_* queries, it means
that you have at least one corrupted index.  You could fix the situation (at
least for this specific problem) with a
REINDEX TABLE pg_proc;

But you will have to investigate how you get a corruption in the first place
(faulty hardware, inadequate configuration...), and maybe do more thorough
checks on your database(s).  See for instance
https://www.postgresql.org/docs/11/amcheck.html.

PG Bug reporting form <noreply@postgresql.org> writes:
> pg_dump: query returned 0 rows instead of one: 
> SELECT proretset, prosrc, probin, pg_catalog.pg_get_function_arguments(oid)
> AS funcargs,pg_catalog.pg_get_function_identity_arguments(oid) AS funciargs,
> pg_catalog.pg_get_function_result(oid) AS funcresult,
> array_to_string(protrftypes, ' ') AS protrftypes, prokind, provolatile,
> proisstrict, prosecdef, proleakproof, proconfig, procost, prorows,
> proparallel, (SELECT lanname FROM pg_catalog.pg_language WHERE oid =
> prolang) AS lanname FROM pg_catalog.pg_proc WHERE oid =
> '1046460'::pg_catalog.oid

If it's repeatable, maybe reindexing pg_proc would help.

            regards, tom lane