It is possible to upgrade on pg_upgrade on streaming standby servers by
making them master servers, running pg_upgrade on them, then shuting
down all servers and using rsync to make the standby servers match the
real master.
However, Josh Berkus reported that he found that hint bits set on the
master server but not on the standby servers made rsync too slow.
The attached pg_upgrade doc patch recommends using wal_log_hints to make
hint bits on the standby match the master. One question I have is
whether hint bits are set by read-only transactions on standby servers.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index e1cd260..07cb1f9
*** a/doc/src/sgml/pgupgrade.sgml
--- b/doc/src/sgml/pgupgrade.sgml
*************** psql --username postgres --file script.s
*** 553,559 ****
is to upgrade the primary and use <command>rsync</> to rebuild the
standbys. You can run <command>rsync</> while the primary is down,
or as part of a base backup (<xref linkend="backup-base-backup">)
! which overwrites the old standby cluster.
</para>
<para>
--- 553,565 ----
is to upgrade the primary and use <command>rsync</> to rebuild the
standbys. You can run <command>rsync</> while the primary is down,
or as part of a base backup (<xref linkend="backup-base-backup">)
! which overwrites the old standby cluster. Hint bit differences
! between the primary and standby can cause <command>rsync</> to copy
! additional data — these differences can be reduced by using
! a fresh standby and by enabling <xref linkend="guc-wal-log-hints">.
! (While <varname>wal_log_hints</> transfers hint bits from the primary
! to standbys, additional hint bits are still set on the standbys by
! read-only queries.)
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
