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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: andrewbille(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
Date: 2025-10-14 19:36:50
Message-ID: aO6mUj9H2WpEFylG@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-10-14 19:50:15 Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
Previous Message Yuri Zamyatin 2025-10-14 15:51:02 Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade