Re: Pg_upgrade speed for many tables
От | Jeff Janes |
---|---|
Тема | Re: Pg_upgrade speed for many tables |
Дата | |
Msg-id | CAMkU=1z4bV3Z-Tv4EB179hL06RdL6gkQ4iDiHn41e-Gr9DcdSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pg_upgrade speed for many tables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Pg_upgrade speed for many tables
|
Список | pgsql-hackers |
On Mon, Nov 5, 2012 at 1:14 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >> Or have options for pg_dump and pg_restore to insert "set >> synchronous_commit=off" into the SQL stream? > > It would be kind of neat if we had a command that would force all > previously-asynchronous commits to complete. It seems likely that > very, very few people would care about intermediate pg_dump states, so > we could do the whole dump asynchronously and then do "FORCE ALL > COMMITS;" or whatever at the end. Yeah, I was wondering what a fool-proof way of doing that would be, without implementing a new feature. Turning synchronous_commits back on and then doing and committing a transaction guaranteed to generate WAL would do it. Would a simple 'select pg_switch_xlog();' always accomplish the desired flush? Cheers, Jeff
В списке pgsql-hackers по дате отправления: