Re: pg_upgrade failing for 200+ million Large Objects
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade failing for 200+ million Large Objects |
Дата | |
Msg-id | 1217588.1711999706@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade failing for 200+ million Large Objects (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_upgrade failing for 200+ million Large Objects
Re: pg_upgrade failing for 200+ million Large Objects |
Список | pgsql-hackers |
Nathan Bossart <nathandbossart@gmail.com> writes: > Sorry for taking so long to get back to this one. Overall, I think the > code is in decent shape. Thanks for looking at it! > The one design point that worries me a little is the non-configurability of > --transaction-size in pg_upgrade. I think it's fine to default it to 1,000 > or something, but given how often I've had to fiddle with > max_locks_per_transaction, I'm wondering if we might regret hard-coding it. Well, we could add a command-line switch to pg_upgrade, but I'm unconvinced that it'd be worth the trouble. I think a very large fraction of users invoke pg_upgrade by means of packager-supplied scripts that are unlikely to provide a way to pass through such a switch. I'm inclined to say let's leave it as-is until we get some actual field requests for a switch. regards, tom lane
В списке pgsql-hackers по дате отправления: