pgsql: Introduce wal_level GUC to explicitly control if information
От | heikki@postgresql.org (Heikki Linnakangas) |
---|---|
Тема | pgsql: Introduce wal_level GUC to explicitly control if information |
Дата | |
Msg-id | 20100428161044.297C77541D0@cvs.postgresql.org обсуждение исходный текст |
Ответы |
Re: pgsql: Introduce wal_level GUC to explicitly control
if information
(Thom Brown <thombrown@gmail.com>)
|
Список | pgsql-committers |
Log Message: ----------- Introduce wal_level GUC to explicitly control if information needed for archival or hot standby should be WAL-logged, instead of deducing that from other options like archive_mode. This replaces recovery_connections GUC in the primary, where it now has no effect, but it's still used in the standby to enable/disable hot standby. Remove the WAL-logging of "unlogged operations", like creating an index without WAL-logging and fsyncing it at the end. Instead, we keep a copy of the wal_mode setting and the settings that affect how much shared memory a hot standby server needs to track master transactions (max_connections, max_prepared_xacts, max_locks_per_xact) in pg_control. Whenever the settings change, at server restart, write a WAL record noting the new settings and update pg_control. This allows us to notice the change in those settings in the standby at the right moment, they used to be included in checkpoint records, but that meant that a changed value was not reflected in the standby until the first checkpoint after the change. Bump PG_CONTROL_VERSION and XLOG_PAGE_MAGIC. Whack XLOG_PAGE_MAGIC back to the sequence it used to follow, before hot standby and subsequent patches changed it to 0x9003. Modified Files: -------------- pgsql/doc/src/sgml: backup.sgml (r2.152 -> r2.153) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/backup.sgml?r1=2.152&r2=2.153) config.sgml (r1.270 -> r1.271) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.270&r2=1.271) high-availability.sgml (r1.63 -> r1.64) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/high-availability.sgml?r1=1.63&r2=1.64) perform.sgml (r1.76 -> r1.77) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/perform.sgml?r1=1.76&r2=1.77) pgsql/src/backend/access/heap: rewriteheap.c (r1.21 -> r1.22) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/rewriteheap.c?r1=1.21&r2=1.22) pgsql/src/backend/access/nbtree: nbtsort.c (r1.124 -> r1.125) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtsort.c?r1=1.124&r2=1.125) pgsql/src/backend/access/transam: xlog.c (r1.404 -> r1.405) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.404&r2=1.405) pgsql/src/backend/commands: cluster.c (r1.202 -> r1.203) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/cluster.c?r1=1.202&r2=1.203) copy.c (r1.326 -> r1.327) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/copy.c?r1=1.326&r2=1.327) tablecmds.c (r1.329 -> r1.330) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.329&r2=1.330) pgsql/src/backend/executor: execMain.c (r1.348 -> r1.349) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c?r1=1.348&r2=1.349) pgsql/src/backend/postmaster: postmaster.c (r1.605 -> r1.606) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/postmaster.c?r1=1.605&r2=1.606) pgsql/src/backend/replication: walsender.c (r1.17 -> r1.18) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walsender.c?r1=1.17&r2=1.18) pgsql/src/backend/storage/ipc: standby.c (r1.19 -> r1.20) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/standby.c?r1=1.19&r2=1.20) pgsql/src/backend/utils/misc: guc.c (r1.551 -> r1.552) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.551&r2=1.552) postgresql.conf.sample (r1.284 -> r1.285) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/postgresql.conf.sample?r1=1.284&r2=1.285) pgsql/src/bin/pg_controldata: pg_controldata.c (r1.46 -> r1.47) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/pg_controldata.c?r1=1.46&r2=1.47) pgsql/src/bin/pg_resetxlog: pg_resetxlog.c (r1.78 -> r1.79) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c?r1=1.78&r2=1.79) pgsql/src/include/access: xlog.h (r1.109 -> r1.110) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlog.h?r1=1.109&r2=1.110) xlog_internal.h (r1.32 -> r1.33) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlog_internal.h?r1=1.32&r2=1.33) pgsql/src/include/catalog: pg_control.h (r1.53 -> r1.54) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_control.h?r1=1.53&r2=1.54) pgsql/src/include/replication: walsender.h (r1.2 -> r1.3) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/replication/walsender.h?r1=1.2&r2=1.3)
В списке pgsql-committers по дате отправления:
Предыдущее
От: tgl@postgresql.org (Tom Lane)Дата:
Сообщение: pgsql: Fix contrib/tsearch2 expected results to match recent changes in
Следующее
От: Thom BrownДата:
Сообщение: Re: pgsql: Introduce wal_level GUC to explicitly control if information