Re: Invalid indexes should not consume update overhead

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Invalid indexes should not consume update overhead
Дата
Msg-id
1150.1468717127@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Invalid indexes should not consume update overhead Tomasz Ostrowski <tometzky+pg@ato.waw.pl>
Re: Invalid indexes should not consume update overhead Amit Kapila <amit.kapila16@gmail.com>
Re: Invalid indexes should not consume update overhead Greg Stark <stark@mit.edu>
Re: Invalid indexes should not consume update overhead Tom Lane <tgl@sss.pgh.pa.us>
Re: Invalid indexes should not consume update overhead Peter Geoghegan <pg@heroku.com>
Re: Invalid indexes should not consume update overhead Tomasz Ostrowski <tometzky+pg@ato.waw.pl>
Re: Invalid indexes should not consume update overhead Peter Geoghegan <pg@heroku.com>
Re: Invalid indexes should not consume update overhead "Rader, David" <davidr@openscg.com>
Re: Invalid indexes should not consume update overhead Jan Wieck <jan@wi3ck.info>
Re: Invalid indexes should not consume update overhead "Rader, David" <davidr@openscg.com>
Re: Invalid indexes should not consume update overhead Peter Geoghegan <pg@heroku.com>
Re: Invalid indexes should not consume update overhead "Rader, David" <davidr@openscg.com>
Re: Invalid indexes should not consume update overhead Tomasz Ostrowski <tometzky+pg@ato.waw.pl>
Re: Invalid indexes should not consume update overhead Jan Wieck <jan@wi3ck.info>
Greg Stark  writes:
> The real solution imho is to actually clean up failed index builds when a
> build fails. That's what normal transactions do when they abort after all.
> This was always the intention but looked like it was going to be a pain and
> was put off (ie I was lazy). It's probably just several layers of
> PG_TRY/PG_CATCH and closing the failed transactions and opening new ones.

No, that wouldn't fix it if the reason the build failed was a crash.

			regards, tom lane
В списке pgsql-bugs по дате отправления
От: Greg Stark
Дата:
От: digoal@126.com
Дата:
FAQ