Обсуждение: pgsql: Introduce wal_level GUC to explicitly control if information

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)

Thom Brown wrote:
> Just a couple, both in the same file:
>
> doc/src/sgml/perform.sgml - s/arcive_mode/archive_mode/ and

Thanks!

> s/afterwards/afterward/

Aren't they interchangeable? Searching the web for "afterward
afterwrads" turns up various discussion forums, and most seem to
consider them both correct. And we use "afterwards" elsewhere in the docs.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Thom Brown wrote:
>> s/afterwards/afterward/

> Aren't they interchangeable? Searching the web for "afterward
> afterwrads" turns up various discussion forums, and most seem to
> consider them both correct. And we use "afterwards" elsewhere in the docs.

... including in some pre-existing places in the same file.  I think it's
okay as-is.

            regards, tom lane