Re: pg_upgrade and wraparound

Поиск
Список
Период
Сортировка
Искать
От
Daniel Verite
Тема
Re: pg_upgrade and wraparound
Дата
Msg-id
ed7d86a1-b907-4f53-9f6e-63482d2f2bac@manitou-mail.org
Ответ на
Список
Дерево обсуждения
pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Adrian Klaver <adrian.klaver@aklaver.com>
Re: pg_upgrade and wraparound Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Adrian Klaver <adrian.klaver@aklaver.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Adrian Klaver <adrian.klaver@aklaver.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Adrian Klaver <adrian.klaver@aklaver.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Adrian Klaver <adrian.klaver@aklaver.com>
Re: pg_upgrade and wraparound Andres Freund <andres@anarazel.de>
Re: pg_upgrade and wraparound Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_upgrade and wraparound Andres Freund <andres@anarazel.de>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Adrian Klaver <adrian.klaver@aklaver.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound "Daniel Verite" <daniel@manitou-mail.org>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound "Daniel Verite" <daniel@manitou-mail.org>
Re: pg_upgrade and wraparound Arjen Nienhuis <a.g.nienhuis@gmail.com>
Re: pg_upgrade and wraparound Alexander Shutyaev <shutyaev@gmail.com>
Re: pg_upgrade and wraparound Andres Freund <andres@anarazel.de>
	Andres Freund wrote:

> I'm not entirely clear why pg_restore appears to use a separate
> transaction for each large object, surely exascerbating the problem.

To make sure that per-object locks don't fill up the shared
lock table?
There might be hundreds of thousands of large objects.
If it had to restore N objects per transaction, would it know
how to compute N that is large enough to be effective
and small enough not to exhaust the shared table?

Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

В списке pgsql-general по дате отправления
От: Bo Peng
Дата:
От: David G. Johnston
Дата:
FAQ