Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
От | Andrew Bille |
---|---|
Тема | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |
Дата | |
Msg-id | CAJnzaryHjaF9WX0eHaKHM-DnV_5z8osC5hL9jyVeoVgjt3dXkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
|
Список | pgsql-bugs |
> 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
В списке pgsql-bugs по дате отправления: