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@gmail.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
>