Date: Tue, 14 Oct 2025 14:36:50 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: andrewbille@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19086: pg_dump --data-only selects and do not uses index
 definitions for the dumped tables.
Message-ID: <aO6mUj9H2WpEFylG@nathan>
References: <19086-871ff11017d03dc5@postgresql.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <19086-871ff11017d03dc5@postgresql.org>
Archived-At: <https://www.postgresql.org/message-id/aO6mUj9H2WpEFylG%40nathan>
Precedence: bulk

On Tue, Oct 14, 2025 at 08:13:52AM +0000, PG Bug reporting form wrote:
> In case of system indexes corruption the collecting of index definitions can
> take a really long time.

I don't think this qualifies as a bug, but avoiding pg_dump queries when
possible seems like a good idea.  Is this a hypothetical problem or
something you've experienced?

> -       pg_log_info("reading indexes");
> -       getIndexes(fout, tblinfo, numTables);
> +       if (!dataOnly)
> +       {
> +               pg_log_info("reading indexes");
> +               getIndexes(fout, tblinfo, numTables);
> 
> -       pg_log_info("flagging indexes in partitioned tables");
> -       flagInhIndexes(fout, tblinfo, numTables);
> +               pg_log_info("flagging indexes in partitioned tables");
> +               flagInhIndexes(fout, tblinfo, numTables);
> +       }

I think we ordinarily leave it up to the get*() functions to return early.
For example, getPartitioningInfo() has this near the top:

	/* needn't bother if not dumping data */
	if (!fout->dopt->dumpData)
		return;

Also, we need to be certain that nothing getIndexes() gathers is ever used
for --data-only dumps.  That seems plausible, but I haven't looked closely.

-- 
nathan