Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
От | Nathan Bossart |
---|---|
Тема | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |
Дата | |
Msg-id | aO6mUj9H2WpEFylG@nathan обсуждение исходный текст |
Ответ на | BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |
Список | 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
В списке pgsql-bugs по дате отправления: