Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.

> Is this a hypothetical problem or something you've experienced?

The problem is real: when trying to rescue data from a large corrupted
database, we couldn't wait for the index definition query for more than 3
hours.

On Wed, Oct 15, 2025 at 2:36 AM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:

> 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
>