Re: optimizing pg_upgrade's once-in-each-database steps
Daniel Gustafsson <daniel@yesql.se>
I've read and tested through the latest version of this patchset and I think it's ready to go in. The one concern I have is that tasks can exit(1) on libpq errors tearing down perfectly functional connections without graceful shutdown. Longer term I think it would make sense to add similar exit handler callbacks to the ones in pg_dump for graceful cleanup of connections. However, in order to keep goalposts in clear view I don't think this patch need to have it, but it would be good to consider once in. Spotted a small typo in the comments: + * nothing to process. This is primarily intended for the inital step in s/inital/initial/ -- Daniel Gustafsson
Commits
-
Introduce framework for parallelizing various pg_upgrade tasks.
- 40e2e5e92b7d 18.0 landed
-
pg_upgrade: Parallelize WITH OIDS check.
- f93f5f7b984e 18.0 landed
-
pg_upgrade: Parallelize contrib/isn check.
- 9db3018cf83b 18.0 landed
-
pg_upgrade: Parallelize data type checks.
- bbf83cab98f2 18.0 landed
-
pg_upgrade: Parallelize encoding conversion check.
- c880cf258864 18.0 landed
-
pg_upgrade: Parallelize incompatible polymorphics check.
- cf2f82a37cc3 18.0 landed
-
pg_upgrade: Parallelize postfix operator check.
- c34eabfbbfd3 18.0 landed
-
pg_upgrade: Parallelize retrieving extension updates.
- 6ab8f27bc716 18.0 landed
-
pg_upgrade: Parallelize retrieving loadable libraries.
- 46cad8b31927 18.0 landed
-
pg_upgrade: Parallelize retrieving relation information.
- 6d3d2e8e541f 18.0 landed
-
pg_upgrade: Parallelize subscription check.
- 7baa36de58bd 18.0 landed
-
pg_upgrade: Move live_check variable to user_opts.
- 4b56bb4ab485 18.0 landed
-
pg_upgrade: run all data type checks per connection
- 347758b12063 17.0 cited