| От | Nathan Bossart |
|---|---|
| Тема | Re: improve performance of pg_dump with many sequences |
| Дата | |
| Msg-id | aWAGxA8igE1ZG_Xq@nathan обсуждение исходный текст |
| Ответ на | Re: improve performance of pg_dump with many sequences (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: improve performance of pg_dump with many sequences
|
| Список | pgsql-hackers |
On Thu, Jan 08, 2026 at 01:19:39PM -0500, Tom Lane wrote: > One nitpicky point is that try_sequence_open() will still error out > if it is given an OID that is a non-sequence relation. I think it'd > be more desirable for it to close the relation again and return NULL. > That's probably insignificant for pg_dump's usage, because we could > only hit the case with very improbable OID wraparound timing. But > I think our experience with catalog-inspection functions similar to > pg_get_sequence_data is that it's usually better to return NULL than > throw an error. Hm. That makes sense, but both try_table_open and try_index_open error for wrong relkinds. I could change all of the try_*_open functions to return NULL in that case, or I could just open-code the relkind check in pg_get_sequence_data after try_relation_open (and have it return NULL for non-sequences). I'm leaning towards the latter, if for no other reason than it might be slightly nicer for back-patching (e.g., smaller, no new extern functions). -- nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера