Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables.
От | Tom Lane |
---|---|
Тема | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |
Дата | |
Msg-id | 1000041.1760471415@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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 |
Nathan Bossart <nathandbossart@gmail.com> writes: > 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? Even if it's been seen in the field, it hardly qualifies as a justification for complicating pg_dump's behavior. There's no reason to think that catalog corruption preferentially affects indexes, or does so in this particular way. Should we also not collect data on functions, types, etc etc? > 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. Yeah, that's the main thing I'd worry about here. For example, ignoring some objects would likely lead to different conclusions about the database objects' dependency web, possibly leading to changes in dump order or other effects. Maybe there's no problem in practice, but this unsupported bug report doesn't really motivate me to do the analysis to see if it'd be all right. regards, tom lane
В списке pgsql-bugs по дате отправления: