Thread: pgsql: Skip WAL for new relfilenodes, under wal_level=minimal.

pgsql: Skip WAL for new relfilenodes, under wal_level=minimal.

From
Noah Misch
Date:
Skip WAL for new relfilenodes, under wal_level=minimal.

Until now, only selected bulk operations (e.g. COPY) did this.  If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules.  Maintainers of table access
methods should examine that section.

To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL.  A new GUC,
wal_skip_threshold, guides that choice.  If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.

Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode.  Introduce rd_firstRelfilenodeSubid.  Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node.  Make relcache.c retain entries for certain
dropped relations until end of transaction.

Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
Future servers accept older WAL, so this bump is discretionary.

Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas.  Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem.  Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs.  Reported by Martijn van Oosterhout.

Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/c6b92041d38512a4176ed76ad06f713d2e6c01a8

Modified Files
--------------
contrib/pg_visibility/expected/pg_visibility.out |  35 +++
contrib/pg_visibility/sql/pg_visibility.sql      |  19 ++
doc/src/sgml/config.sgml                         |  40 ++-
doc/src/sgml/perform.sgml                        |  47 +--
src/backend/access/gist/gistutil.c               |  31 +-
src/backend/access/gist/gistxlog.c               |  21 ++
src/backend/access/heap/heapam.c                 |  45 +--
src/backend/access/heap/heapam_handler.c         |  22 +-
src/backend/access/heap/rewriteheap.c            |  21 +-
src/backend/access/nbtree/nbtsort.c              |  41 +--
src/backend/access/rmgrdesc/gistdesc.c           |   6 +
src/backend/access/transam/README                |  45 ++-
src/backend/access/transam/parallel.c            |  26 +-
src/backend/access/transam/xact.c                |  15 +
src/backend/access/transam/xlogutils.c           |  18 +-
src/backend/bootstrap/bootparse.y                |   4 +
src/backend/catalog/storage.c                    | 333 +++++++++++++++++++-
src/backend/commands/cluster.c                   |  19 ++
src/backend/commands/copy.c                      |  58 +---
src/backend/commands/createas.c                  |  11 +-
src/backend/commands/indexcmds.c                 |   2 +
src/backend/commands/matview.c                   |  12 +-
src/backend/commands/tablecmds.c                 |  26 +-
src/backend/nodes/copyfuncs.c                    |   2 +
src/backend/nodes/equalfuncs.c                   |   2 +
src/backend/nodes/outfuncs.c                     |   2 +
src/backend/parser/gram.y                        |   4 +
src/backend/parser/parse_utilcmd.c               |   4 +
src/backend/storage/buffer/bufmgr.c              | 125 +++++++-
src/backend/storage/lmgr/lock.c                  |  12 +
src/backend/storage/smgr/md.c                    |  36 ++-
src/backend/storage/smgr/smgr.c                  |  35 +++
src/backend/utils/cache/relcache.c               | 283 +++++++++++++----
src/backend/utils/misc/guc.c                     |  12 +
src/backend/utils/misc/postgresql.conf.sample    |   1 +
src/include/access/gist_private.h                |   2 +
src/include/access/gistxlog.h                    |   1 +
src/include/access/heapam.h                      |   3 -
src/include/access/rewriteheap.h                 |   2 +-
src/include/access/tableam.h                     |  15 +-
src/include/access/xlog_internal.h               |   2 +-
src/include/catalog/storage.h                    |   9 +
src/include/nodes/parsenodes.h                   |   3 +
src/include/storage/bufmgr.h                     |   4 +
src/include/storage/lock.h                       |   3 +
src/include/storage/smgr.h                       |   1 +
src/include/utils/rel.h                          |  55 +++-
src/include/utils/relcache.h                     |   8 +-
src/test/recovery/t/018_wal_optimize.pl          | 372 +++++++++++++++++++++++
src/test/regress/expected/alter_table.out        |   6 +
src/test/regress/expected/create_table.out       |  13 +
src/test/regress/sql/alter_table.sql             |   7 +
src/test/regress/sql/create_table.sql            |  15 +
53 files changed, 1565 insertions(+), 371 deletions(-)


Re: pgsql: Skip WAL for new relfilenodes, under wal_level=minimal.

From
Michael Paquier
Date:
Hi Noah,

On Sat, Apr 04, 2020 at 08:40:43PM +0000, Noah Misch wrote:
> Skip WAL for new relfilenodes, under wal_level=minimal.
>
> Until now, only selected bulk operations (e.g. COPY) did this.  If a
> given relfilenode received both a WAL-skipping COPY and a WAL-logged
> operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
> src/backend/access/transam/README section "Skipping WAL for New
> RelFileNode" for the new coding rules.  Maintainers of table access
> methods should examine that section.
>
> To maintain data durability, just before commit, we choose between an
> fsync of the relfilenode and copying its contents to WAL.  A new GUC,
> wal_skip_threshold, guides that choice.  If this change slows a workload
> that creates small, permanent relfilenodes under wal_level=minimal, try
> adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may
> need to adjust that timeout, and log_min_duration_statement analysis
> will reflect time consumption moving to COMMIT from commands like COPY.

+   /*
+    * Records other than SWITCH_WAL must have content. We use an integer 0 to
+    * follow the restriction.
+    */
This commit has added the following comment, but I guess you meant
XLOG_SWITCH instead?
--
Michael

Attachment

Re: pgsql: Skip WAL for new relfilenodes, under wal_level=minimal.

From
Kyotaro Horiguchi
Date:
At Fri, 24 Apr 2020 16:29:41 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> Hi Noah,
> 
> On Sat, Apr 04, 2020 at 08:40:43PM +0000, Noah Misch wrote:
> > Skip WAL for new relfilenodes, under wal_level=minimal.
> > 
> > Until now, only selected bulk operations (e.g. COPY) did this.  If a
> > given relfilenode received both a WAL-skipping COPY and a WAL-logged
> > operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
> > src/backend/access/transam/README section "Skipping WAL for New
> > RelFileNode" for the new coding rules.  Maintainers of table access
> > methods should examine that section.
> > 
> > To maintain data durability, just before commit, we choose between an
> > fsync of the relfilenode and copying its contents to WAL.  A new GUC,
> > wal_skip_threshold, guides that choice.  If this change slows a workload
> > that creates small, permanent relfilenodes under wal_level=minimal, try
> > adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may
> > need to adjust that timeout, and log_min_duration_statement analysis
> > will reflect time consumption moving to COMMIT from commands like COPY.
> 
> +   /*
> +    * Records other than SWITCH_WAL must have content. We use an integer 0 to
> +    * follow the restriction.
> +    */
> This commit has added the following comment, but I guess you meant
> XLOG_SWITCH instead?

Oops, I'm the one to blame on it. Actually it is a mistake of
XLOG_SWITCH.  By the way, the "xlog-switch" in the following comment
might be better to be XLOG_SWITCH.

>    /* All (non xlog-switch) records should contain data. */

There are several other occurances of xlog-switch.

ragards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center