On Wed, Mar 4, 2015 at 01:53:47PM +0300, Vladimir Borodin wrote: > After running initdb to create the new master, but before running > pg_upgrade, modify the new master's postgresql.conf and change wal_level > = hot_standby. (Don't modify pg_hba.conf at this stage.) > > > > That does not help. The reason is that pg_upgrade sets 'Current wal_level > setting: minimal' in control-file, and it does not depend on what is set in > postgresql.conf before running pg_upgrade. Details could be seen here - > http:// > pastie.org/9998671.
Well, what is happening is that the pg_resetxlog commands we run inside pg_upgrade set the pg_controldata file's wal_level to minimal, but as you saw, starting the server sets the pg_controldata properly. pg_resetxlog is not changing the WAL files at all, just the control file. > The workaround for this is to start and cleanly shut down postgres on master > after running pg_upgrade but before running rsync. After that there would be a > good control-file for streaming replication and rsync to replica can be done. You are correct that a pg_controldata file is copied over that has wal_level=minimal, but that should not be a problem. > But it could not be done with --size-only key, because control-file is of > fixed > size and rsync would skip it. Or may be everything should be copied with > --size-only and control-file should be copied without this option. Well, what happens is that there is no _new_ standby pg_controldata file, so it is copied fully from the new master. Are you running initdb to create the new standby --- you shouldn't be doing that as the rsync will do that for you. Also, are you cleanly shutting down all the servers, or using pg_ctl -m immediate? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
