public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 5/8] Add zlib compression method
23+ messages / 8 participants
[nested] [flat]
* [PATCH 5/8] Add zlib compression method
@ 2018-06-18 12:51 Ildus Kurbangaliev <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Ildus Kurbangaliev @ 2018-06-18 12:51 UTC (permalink / raw)
Signed-off-by: Ildus Kurbangaliev <[email protected]>
---
src/backend/Makefile | 2 +-
src/backend/access/compression/Makefile | 2 +-
src/backend/access/compression/cm_zlib.c | 252 ++++++++++++++++++++
src/include/catalog/pg_am.dat | 3 +
src/include/catalog/pg_attr_compression.dat | 1 +
src/include/catalog/pg_proc.dat | 4 +
6 files changed, 262 insertions(+), 2 deletions(-)
create mode 100644 src/backend/access/compression/cm_zlib.c
diff --git a/src/backend/Makefile b/src/backend/Makefile
index 478a96db9b..bd5009e190 100644
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -45,7 +45,7 @@ OBJS = $(SUBDIROBJS) $(LOCALOBJS) $(top_builddir)/src/port/libpgport_srv.a \
LIBS := $(filter-out -lpgport -lpgcommon, $(LIBS)) $(LDAP_LIBS_BE) $(ICU_LIBS)
# The backend doesn't need everything that's in LIBS, however
-LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS))
+LIBS := $(filter-out -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS))
ifeq ($(with_systemd),yes)
LIBS += -lsystemd
diff --git a/src/backend/access/compression/Makefile b/src/backend/access/compression/Makefile
index 14286920d3..7ea5ee2e43 100644
--- a/src/backend/access/compression/Makefile
+++ b/src/backend/access/compression/Makefile
@@ -12,6 +12,6 @@ subdir = src/backend/access/compression
top_builddir = ../../../..
include $(top_builddir)/src/Makefile.global
-OBJS = cm_pglz.o cmapi.o
+OBJS = cm_pglz.o cm_zlib.o cmapi.o
include $(top_srcdir)/src/backend/common.mk
diff --git a/src/backend/access/compression/cm_zlib.c b/src/backend/access/compression/cm_zlib.c
new file mode 100644
index 0000000000..0dcb56ddf3
--- /dev/null
+++ b/src/backend/access/compression/cm_zlib.c
@@ -0,0 +1,252 @@
+/*-------------------------------------------------------------------------
+ *
+ * cm_zlib.c
+ * zlib compression method
+ *
+ * Copyright (c) 2015-2018, PostgreSQL Global Development Group
+ *
+ *
+ * IDENTIFICATION
+ * src/backend/access/compression/cm_zlib.c
+ *
+ *-------------------------------------------------------------------------
+ */
+#include "postgres.h"
+#include "access/cmapi.h"
+#include "commands/defrem.h"
+#include "nodes/parsenodes.h"
+#include "utils/builtins.h"
+
+#ifdef HAVE_LIBZ
+#include <zlib.h>
+
+#define ZLIB_MAX_DICTIONARY_LENGTH 32768
+#define ZLIB_DICTIONARY_DELIM (" ,")
+
+typedef struct
+{
+ int level;
+ Bytef dict[ZLIB_MAX_DICTIONARY_LENGTH];
+ unsigned int dictlen;
+} zlib_state;
+
+/*
+ * Check options if specified. All validation is located here so
+ * we don't need do it again in cminitstate function.
+ */
+static void
+zlib_cmcheck(Form_pg_attribute att, List *options)
+{
+ ListCell *lc;
+ foreach(lc, options)
+ {
+ DefElem *def = (DefElem *) lfirst(lc);
+
+ if (strcmp(def->defname, "level") == 0)
+ {
+ if (strcmp(defGetString(def), "best_speed") != 0 &&
+ strcmp(defGetString(def), "best_compression") != 0 &&
+ strcmp(defGetString(def), "default") != 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("unexpected value for zlib compression level: \"%s\"", defGetString(def))));
+ }
+ else if (strcmp(def->defname, "dict") == 0)
+ {
+ int ntokens = 0;
+ char *val,
+ *tok;
+
+ val = pstrdup(defGetString(def));
+ if (strlen(val) > (ZLIB_MAX_DICTIONARY_LENGTH - 1))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ (errmsg("zlib dictionary length should be less than %d", ZLIB_MAX_DICTIONARY_LENGTH))));
+
+ while ((tok = strtok(val, ZLIB_DICTIONARY_DELIM)) != NULL)
+ {
+ ntokens++;
+ val = NULL;
+ }
+
+ if (ntokens < 2)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ (errmsg("zlib dictionary is too small"))));
+ }
+ else
+ ereport(ERROR,
+ (errcode(ERRCODE_UNDEFINED_PARAMETER),
+ errmsg("unexpected parameter for zlib: \"%s\"", def->defname)));
+ }
+}
+
+static void *
+zlib_cminitstate(Oid acoid, List *options)
+{
+ zlib_state *state = NULL;
+
+ state = palloc0(sizeof(zlib_state));
+ state->level = Z_DEFAULT_COMPRESSION;
+
+ if (list_length(options) > 0)
+ {
+ ListCell *lc;
+
+ foreach(lc, options)
+ {
+ DefElem *def = (DefElem *) lfirst(lc);
+
+ if (strcmp(def->defname, "level") == 0)
+ {
+ if (strcmp(defGetString(def), "best_speed") == 0)
+ state->level = Z_BEST_SPEED;
+ else if (strcmp(defGetString(def), "best_compression") == 0)
+ state->level = Z_BEST_COMPRESSION;
+ }
+ else if (strcmp(def->defname, "dict") == 0)
+ {
+ char *val,
+ *tok;
+
+ val = pstrdup(defGetString(def));
+
+ /* Fill the zlib dictionary */
+ while ((tok = strtok(val, ZLIB_DICTIONARY_DELIM)) != NULL)
+ {
+ int len = strlen(tok);
+ memcpy((void *) (state->dict + state->dictlen), tok, len);
+ state->dictlen += len + 1;
+ Assert(state->dictlen <= ZLIB_MAX_DICTIONARY_LENGTH);
+
+ /* add space as dictionary delimiter */
+ state->dict[state->dictlen - 1] = ' ';
+ val = NULL;
+ }
+ }
+ }
+ }
+
+ return state;
+}
+
+static struct varlena *
+zlib_cmcompress(CompressionAmOptions *cmoptions, const struct varlena *value)
+{
+ int32 valsize,
+ len;
+ struct varlena *tmp = NULL;
+ z_streamp zp;
+ int res;
+ zlib_state *state = (zlib_state *) cmoptions->acstate;
+
+ zp = (z_streamp) palloc(sizeof(z_stream));
+ zp->zalloc = Z_NULL;
+ zp->zfree = Z_NULL;
+ zp->opaque = Z_NULL;
+
+ if (deflateInit(zp, state->level) != Z_OK)
+ elog(ERROR, "could not initialize compression library: %s", zp->msg);
+
+ if (state->dictlen > 0)
+ {
+ res = deflateSetDictionary(zp, state->dict, state->dictlen);
+ if (res != Z_OK)
+ elog(ERROR, "could not set dictionary for zlib: %s", zp->msg);
+ }
+
+ valsize = VARSIZE_ANY_EXHDR(DatumGetPointer(value));
+ tmp = (struct varlena *) palloc(valsize + VARHDRSZ_CUSTOM_COMPRESSED);
+ zp->next_in = (void *) VARDATA_ANY(value);
+ zp->avail_in = valsize;
+ zp->avail_out = valsize;
+ zp->next_out = (void *)((char *) tmp + VARHDRSZ_CUSTOM_COMPRESSED);
+
+ do {
+ res = deflate(zp, Z_FINISH);
+ if (res == Z_STREAM_ERROR)
+ elog(ERROR, "could not compress data: %s", zp->msg);
+ } while (zp->avail_in != 0);
+
+ Assert(res == Z_STREAM_END);
+
+ len = valsize - zp->avail_out;
+ if (deflateEnd(zp) != Z_OK)
+ elog(ERROR, "could not close compression stream: %s", zp->msg);
+ pfree(zp);
+
+ if (len > 0)
+ {
+ SET_VARSIZE_COMPRESSED(tmp, len + VARHDRSZ_CUSTOM_COMPRESSED);
+ return tmp;
+ }
+
+ pfree(tmp);
+#endif
+ return NULL;
+}
+
+static struct varlena *
+zlib_cmdecompress(CompressionAmOptions *cmoptions, const struct varlena *value)
+{
+ struct varlena *result;
+ z_streamp zp;
+ int res = Z_OK;
+ zlib_state *state = (zlib_state *) cmoptions->acstate;
+
+ zp = (z_streamp) palloc(sizeof(z_stream));
+ zp->zalloc = Z_NULL;
+ zp->zfree = Z_NULL;
+ zp->opaque = Z_NULL;
+
+ if (inflateInit(zp) != Z_OK)
+ elog(ERROR, "could not initialize compression library: %s", zp->msg);
+
+ Assert(VARATT_IS_CUSTOM_COMPRESSED(value));
+ zp->next_in = (void *) ((char *) value + VARHDRSZ_CUSTOM_COMPRESSED);
+ zp->avail_in = VARSIZE(value) - VARHDRSZ_CUSTOM_COMPRESSED;
+ zp->avail_out = VARRAWSIZE_4B_C(value);
+
+ result = (struct varlena *) palloc(zp->avail_out + VARHDRSZ);
+ SET_VARSIZE(result, zp->avail_out + VARHDRSZ);
+ zp->next_out = (void *) VARDATA(result);
+
+ while (zp->avail_in > 0)
+ {
+ res = inflate(zp, 0);
+ if (res == Z_NEED_DICT && state->dictlen > 0)
+ {
+ res = inflateSetDictionary(zp, state->dict, state->dictlen);
+ if (res != Z_OK)
+ elog(ERROR, "could not set dictionary for zlib");
+ continue;
+ }
+ if (!(res == Z_OK || res == Z_STREAM_END))
+ elog(ERROR, "could not uncompress data: %s", zp->msg);
+ }
+
+ if (inflateEnd(zp) != Z_OK)
+ elog(ERROR, "could not close compression library: %s", zp->msg);
+
+ pfree(zp);
+ return result;
+}
+
+Datum
+zlibhandler(PG_FUNCTION_ARGS)
+{
+#ifndef HAVE_LIBZ
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("not built with zlib support")));
+#else
+ CompressionAmRoutine *routine = makeNode(CompressionAmRoutine);
+
+ routine->cmcheck = zlib_cmcheck;
+ routine->cminitstate = zlib_cminitstate;
+ routine->cmcompress = zlib_cmcompress;
+ routine->cmdecompress = zlib_cmdecompress;
+
+ PG_RETURN_POINTER(routine);
+#endif
+}
diff --git a/src/include/catalog/pg_am.dat b/src/include/catalog/pg_am.dat
index 4bf1c49d11..16a098d633 100644
--- a/src/include/catalog/pg_am.dat
+++ b/src/include/catalog/pg_am.dat
@@ -36,5 +36,8 @@
{ oid => '4002', oid_symbol => 'PGLZ_COMPRESSION_AM_OID',
descr => 'pglz compression access method',
amname => 'pglz', amhandler => 'pglzhandler', amtype => 'c' },
+{ oid => '4011', oid_symbol => 'ZLIB_COMPRESSION_AM_OID',
+ descr => 'zlib compression access method',
+ amname => 'zlib', amhandler => 'zlibhandler', amtype => 'c' },
]
diff --git a/src/include/catalog/pg_attr_compression.dat b/src/include/catalog/pg_attr_compression.dat
index 4e72bde16c..a7216fe963 100644
--- a/src/include/catalog/pg_attr_compression.dat
+++ b/src/include/catalog/pg_attr_compression.dat
@@ -19,5 +19,6 @@
[
{ acoid => '4002', acname => 'pglz' },
+{ acoid => '4011', acname => 'zlib' },
]
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 5ff8e886bd..2dce2c087d 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -914,6 +914,10 @@
proname => 'pglzhandler', provolatile => 'v',
prorettype => 'compression_am_handler', proargtypes => 'internal',
prosrc => 'pglzhandler' },
+{ oid => '4010', descr => 'zlib compression access method handler',
+ proname => 'zlibhandler', provolatile => 'v',
+ prorettype => 'compression_am_handler', proargtypes => 'internal',
+ prosrc => 'zlibhandler' },
{ oid => '338', descr => 'validate an operator class',
proname => 'amvalidate', provolatile => 'v', prorettype => 'bool',
--
2.21.0
--MP_//XvyHCr_hJMvh/tp2R3=uJa
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=0006-Add-psql-pg_dump-and-pg_upgrade-support-v22.patch
^ permalink raw reply [nested|flat] 23+ messages in thread
* [PATCH 5/8] Add zlib compression method
@ 2018-06-18 12:51 Ildus Kurbangaliev <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Ildus Kurbangaliev @ 2018-06-18 12:51 UTC (permalink / raw)
Signed-off-by: Ildus Kurbangaliev <[email protected]>
---
src/backend/Makefile | 2 +-
src/backend/access/compression/Makefile | 2 +-
src/backend/access/compression/cm_zlib.c | 252 ++++++++++++++++++++
src/include/catalog/pg_am.dat | 3 +
src/include/catalog/pg_attr_compression.dat | 1 +
src/include/catalog/pg_proc.dat | 4 +
6 files changed, 262 insertions(+), 2 deletions(-)
create mode 100644 src/backend/access/compression/cm_zlib.c
diff --git a/src/backend/Makefile b/src/backend/Makefile
index 478a96db9b..bd5009e190 100644
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -45,7 +45,7 @@ OBJS = $(SUBDIROBJS) $(LOCALOBJS) $(top_builddir)/src/port/libpgport_srv.a \
LIBS := $(filter-out -lpgport -lpgcommon, $(LIBS)) $(LDAP_LIBS_BE) $(ICU_LIBS)
# The backend doesn't need everything that's in LIBS, however
-LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS))
+LIBS := $(filter-out -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS))
ifeq ($(with_systemd),yes)
LIBS += -lsystemd
diff --git a/src/backend/access/compression/Makefile b/src/backend/access/compression/Makefile
index 14286920d3..7ea5ee2e43 100644
--- a/src/backend/access/compression/Makefile
+++ b/src/backend/access/compression/Makefile
@@ -12,6 +12,6 @@ subdir = src/backend/access/compression
top_builddir = ../../../..
include $(top_builddir)/src/Makefile.global
-OBJS = cm_pglz.o cmapi.o
+OBJS = cm_pglz.o cm_zlib.o cmapi.o
include $(top_srcdir)/src/backend/common.mk
diff --git a/src/backend/access/compression/cm_zlib.c b/src/backend/access/compression/cm_zlib.c
new file mode 100644
index 0000000000..0dcb56ddf3
--- /dev/null
+++ b/src/backend/access/compression/cm_zlib.c
@@ -0,0 +1,252 @@
+/*-------------------------------------------------------------------------
+ *
+ * cm_zlib.c
+ * zlib compression method
+ *
+ * Copyright (c) 2015-2018, PostgreSQL Global Development Group
+ *
+ *
+ * IDENTIFICATION
+ * src/backend/access/compression/cm_zlib.c
+ *
+ *-------------------------------------------------------------------------
+ */
+#include "postgres.h"
+#include "access/cmapi.h"
+#include "commands/defrem.h"
+#include "nodes/parsenodes.h"
+#include "utils/builtins.h"
+
+#ifdef HAVE_LIBZ
+#include <zlib.h>
+
+#define ZLIB_MAX_DICTIONARY_LENGTH 32768
+#define ZLIB_DICTIONARY_DELIM (" ,")
+
+typedef struct
+{
+ int level;
+ Bytef dict[ZLIB_MAX_DICTIONARY_LENGTH];
+ unsigned int dictlen;
+} zlib_state;
+
+/*
+ * Check options if specified. All validation is located here so
+ * we don't need do it again in cminitstate function.
+ */
+static void
+zlib_cmcheck(Form_pg_attribute att, List *options)
+{
+ ListCell *lc;
+ foreach(lc, options)
+ {
+ DefElem *def = (DefElem *) lfirst(lc);
+
+ if (strcmp(def->defname, "level") == 0)
+ {
+ if (strcmp(defGetString(def), "best_speed") != 0 &&
+ strcmp(defGetString(def), "best_compression") != 0 &&
+ strcmp(defGetString(def), "default") != 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("unexpected value for zlib compression level: \"%s\"", defGetString(def))));
+ }
+ else if (strcmp(def->defname, "dict") == 0)
+ {
+ int ntokens = 0;
+ char *val,
+ *tok;
+
+ val = pstrdup(defGetString(def));
+ if (strlen(val) > (ZLIB_MAX_DICTIONARY_LENGTH - 1))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ (errmsg("zlib dictionary length should be less than %d", ZLIB_MAX_DICTIONARY_LENGTH))));
+
+ while ((tok = strtok(val, ZLIB_DICTIONARY_DELIM)) != NULL)
+ {
+ ntokens++;
+ val = NULL;
+ }
+
+ if (ntokens < 2)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ (errmsg("zlib dictionary is too small"))));
+ }
+ else
+ ereport(ERROR,
+ (errcode(ERRCODE_UNDEFINED_PARAMETER),
+ errmsg("unexpected parameter for zlib: \"%s\"", def->defname)));
+ }
+}
+
+static void *
+zlib_cminitstate(Oid acoid, List *options)
+{
+ zlib_state *state = NULL;
+
+ state = palloc0(sizeof(zlib_state));
+ state->level = Z_DEFAULT_COMPRESSION;
+
+ if (list_length(options) > 0)
+ {
+ ListCell *lc;
+
+ foreach(lc, options)
+ {
+ DefElem *def = (DefElem *) lfirst(lc);
+
+ if (strcmp(def->defname, "level") == 0)
+ {
+ if (strcmp(defGetString(def), "best_speed") == 0)
+ state->level = Z_BEST_SPEED;
+ else if (strcmp(defGetString(def), "best_compression") == 0)
+ state->level = Z_BEST_COMPRESSION;
+ }
+ else if (strcmp(def->defname, "dict") == 0)
+ {
+ char *val,
+ *tok;
+
+ val = pstrdup(defGetString(def));
+
+ /* Fill the zlib dictionary */
+ while ((tok = strtok(val, ZLIB_DICTIONARY_DELIM)) != NULL)
+ {
+ int len = strlen(tok);
+ memcpy((void *) (state->dict + state->dictlen), tok, len);
+ state->dictlen += len + 1;
+ Assert(state->dictlen <= ZLIB_MAX_DICTIONARY_LENGTH);
+
+ /* add space as dictionary delimiter */
+ state->dict[state->dictlen - 1] = ' ';
+ val = NULL;
+ }
+ }
+ }
+ }
+
+ return state;
+}
+
+static struct varlena *
+zlib_cmcompress(CompressionAmOptions *cmoptions, const struct varlena *value)
+{
+ int32 valsize,
+ len;
+ struct varlena *tmp = NULL;
+ z_streamp zp;
+ int res;
+ zlib_state *state = (zlib_state *) cmoptions->acstate;
+
+ zp = (z_streamp) palloc(sizeof(z_stream));
+ zp->zalloc = Z_NULL;
+ zp->zfree = Z_NULL;
+ zp->opaque = Z_NULL;
+
+ if (deflateInit(zp, state->level) != Z_OK)
+ elog(ERROR, "could not initialize compression library: %s", zp->msg);
+
+ if (state->dictlen > 0)
+ {
+ res = deflateSetDictionary(zp, state->dict, state->dictlen);
+ if (res != Z_OK)
+ elog(ERROR, "could not set dictionary for zlib: %s", zp->msg);
+ }
+
+ valsize = VARSIZE_ANY_EXHDR(DatumGetPointer(value));
+ tmp = (struct varlena *) palloc(valsize + VARHDRSZ_CUSTOM_COMPRESSED);
+ zp->next_in = (void *) VARDATA_ANY(value);
+ zp->avail_in = valsize;
+ zp->avail_out = valsize;
+ zp->next_out = (void *)((char *) tmp + VARHDRSZ_CUSTOM_COMPRESSED);
+
+ do {
+ res = deflate(zp, Z_FINISH);
+ if (res == Z_STREAM_ERROR)
+ elog(ERROR, "could not compress data: %s", zp->msg);
+ } while (zp->avail_in != 0);
+
+ Assert(res == Z_STREAM_END);
+
+ len = valsize - zp->avail_out;
+ if (deflateEnd(zp) != Z_OK)
+ elog(ERROR, "could not close compression stream: %s", zp->msg);
+ pfree(zp);
+
+ if (len > 0)
+ {
+ SET_VARSIZE_COMPRESSED(tmp, len + VARHDRSZ_CUSTOM_COMPRESSED);
+ return tmp;
+ }
+
+ pfree(tmp);
+#endif
+ return NULL;
+}
+
+static struct varlena *
+zlib_cmdecompress(CompressionAmOptions *cmoptions, const struct varlena *value)
+{
+ struct varlena *result;
+ z_streamp zp;
+ int res = Z_OK;
+ zlib_state *state = (zlib_state *) cmoptions->acstate;
+
+ zp = (z_streamp) palloc(sizeof(z_stream));
+ zp->zalloc = Z_NULL;
+ zp->zfree = Z_NULL;
+ zp->opaque = Z_NULL;
+
+ if (inflateInit(zp) != Z_OK)
+ elog(ERROR, "could not initialize compression library: %s", zp->msg);
+
+ Assert(VARATT_IS_CUSTOM_COMPRESSED(value));
+ zp->next_in = (void *) ((char *) value + VARHDRSZ_CUSTOM_COMPRESSED);
+ zp->avail_in = VARSIZE(value) - VARHDRSZ_CUSTOM_COMPRESSED;
+ zp->avail_out = VARRAWSIZE_4B_C(value);
+
+ result = (struct varlena *) palloc(zp->avail_out + VARHDRSZ);
+ SET_VARSIZE(result, zp->avail_out + VARHDRSZ);
+ zp->next_out = (void *) VARDATA(result);
+
+ while (zp->avail_in > 0)
+ {
+ res = inflate(zp, 0);
+ if (res == Z_NEED_DICT && state->dictlen > 0)
+ {
+ res = inflateSetDictionary(zp, state->dict, state->dictlen);
+ if (res != Z_OK)
+ elog(ERROR, "could not set dictionary for zlib");
+ continue;
+ }
+ if (!(res == Z_OK || res == Z_STREAM_END))
+ elog(ERROR, "could not uncompress data: %s", zp->msg);
+ }
+
+ if (inflateEnd(zp) != Z_OK)
+ elog(ERROR, "could not close compression library: %s", zp->msg);
+
+ pfree(zp);
+ return result;
+}
+
+Datum
+zlibhandler(PG_FUNCTION_ARGS)
+{
+#ifndef HAVE_LIBZ
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("not built with zlib support")));
+#else
+ CompressionAmRoutine *routine = makeNode(CompressionAmRoutine);
+
+ routine->cmcheck = zlib_cmcheck;
+ routine->cminitstate = zlib_cminitstate;
+ routine->cmcompress = zlib_cmcompress;
+ routine->cmdecompress = zlib_cmdecompress;
+
+ PG_RETURN_POINTER(routine);
+#endif
+}
diff --git a/src/include/catalog/pg_am.dat b/src/include/catalog/pg_am.dat
index adfc10c443..8c101ed157 100644
--- a/src/include/catalog/pg_am.dat
+++ b/src/include/catalog/pg_am.dat
@@ -33,5 +33,8 @@
{ oid => '4002', oid_symbol => 'PGLZ_COMPRESSION_AM_OID',
descr => 'pglz compression access method',
amname => 'pglz', amhandler => 'pglzhandler', amtype => 'c' },
+{ oid => '4011', oid_symbol => 'ZLIB_COMPRESSION_AM_OID',
+ descr => 'zlib compression access method',
+ amname => 'zlib', amhandler => 'zlibhandler', amtype => 'c' },
]
diff --git a/src/include/catalog/pg_attr_compression.dat b/src/include/catalog/pg_attr_compression.dat
index 4e72bde16c..a7216fe963 100644
--- a/src/include/catalog/pg_attr_compression.dat
+++ b/src/include/catalog/pg_attr_compression.dat
@@ -19,5 +19,6 @@
[
{ acoid => '4002', acname => 'pglz' },
+{ acoid => '4011', acname => 'zlib' },
]
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 5b57d46afe..e3dbdb623b 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -907,6 +907,10 @@
proname => 'pglzhandler', provolatile => 'v',
prorettype => 'compression_am_handler', proargtypes => 'internal',
prosrc => 'pglzhandler' },
+{ oid => '4010', descr => 'zlib compression access method handler',
+ proname => 'zlibhandler', provolatile => 'v',
+ prorettype => 'compression_am_handler', proargtypes => 'internal',
+ prosrc => 'zlibhandler' },
{ oid => '338', descr => 'validate an operator class',
proname => 'amvalidate', provolatile => 'v', prorettype => 'bool',
--
2.20.1
--MP_/IoARF=uydinlHTRfc3S.uiA
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=0006-Add-psql-pg_dump-and-pg_upgrade-support-v21.patch
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
@ 2022-03-26 05:56 Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Bharath Rupireddy @ 2022-03-26 05:56 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, Mar 2, 2022 at 11:41 AM Bharath Rupireddy
<[email protected]> wrote:
>
> Please review the v2 patch set.
Had to rebase. Attaching v3 patch set.
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v3-0001-Use-WAL-segment-instead-of-log-segment.patch (9.0K, ../../CALj2ACXhKo857tidmzZCU9f4Oxzgu3DDUj=_MOu14Ohjuk=K4A@mail.gmail.com/2-v3-0001-Use-WAL-segment-instead-of-log-segment.patch)
download | inline diff:
From 54b1370b2092fb12e6ea4832387f4703ad1915b6 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Sat, 26 Mar 2022 05:52:18 +0000
Subject: [PATCH v3] Use "WAL segment" instead of "log segment"
It looks like we use "log segment" in various user-facing messages.
The term "log" can mean server logs as well. The "WAL segment"
suits well here and it is consistently used across the other
user-facing messages.
---
src/backend/access/transam/xlogreader.c | 10 +++++-----
src/backend/access/transam/xlogrecovery.c | 6 +++---
src/backend/access/transam/xlogutils.c | 4 ++--
src/backend/replication/walreceiver.c | 6 +++---
src/bin/pg_resetwal/pg_resetwal.c | 2 +-
src/bin/pg_upgrade/controldata.c | 2 +-
src/bin/pg_waldump/pg_waldump.c | 4 ++--
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index e437c42992..d37bae47f8 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1207,7 +1207,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid magic number %04X in log segment %s, offset %u",
+ "invalid magic number %04X in WAL segment %s, offset %u",
hdr->xlp_magic,
fname,
offset);
@@ -1221,7 +1221,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1262,7 +1262,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
/* hmm, first page of file doesn't have a long header? */
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1281,7 +1281,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "unexpected pageaddr %X/%X in log segment %s, offset %u",
+ "unexpected pageaddr %X/%X in WAL segment %s, offset %u",
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
@@ -1306,7 +1306,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "out-of-sequence timeline ID %u (after %u) in log segment %s, offset %u",
+ "out-of-sequence timeline ID %u (after %u) in WAL segment %s, offset %u",
hdr->xlp_tli,
state->latestPageTLI,
fname,
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 8b22c4e634..f3909213fe 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -2998,7 +2998,7 @@ ReadRecord(XLogReaderState *xlogreader, int emode,
XLogFileName(fname, xlogreader->seg.ws_tli, segno,
wal_segment_size);
ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg("unexpected timeline ID %u in log segment %s, offset %u",
+ (errmsg("unexpected timeline ID %u in WAL segment %s, offset %u",
xlogreader->latestPageTLI,
fname,
offset)));
@@ -3189,13 +3189,13 @@ retry:
errno = save_errno;
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %u: %m",
+ errmsg("could not read from WAL segment %s, offset %u: %m",
fname, readOff)));
}
else
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %u: read %d of %zu",
+ errmsg("could not read from WAL segment %s, offset %u: read %d of %zu",
fname, readOff, r, (Size) XLOG_BLCKSZ)));
goto next_record_is_invalid;
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 8c1b8216be..e49f534c5c 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -1142,14 +1142,14 @@ WALReadRaiseError(WALReadError *errinfo)
errno = errinfo->wre_errno;
ereport(ERROR,
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %d: %m",
+ errmsg("could not read from WAL segment %s, offset %d: %m",
fname, errinfo->wre_off)));
}
else if (errinfo->wre_read == 0)
{
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %d: read %d of %d",
+ errmsg("could not read from WAL segment %s, offset %d: read %d of %d",
fname, errinfo->wre_off, errinfo->wre_read,
errinfo->wre_req)));
}
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index ceaff097b9..94b3f0d016 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -616,7 +616,7 @@ WalReceiverMain(void)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
@@ -930,7 +930,7 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr, TimeLineID tli)
errno = save_errno;
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not write to log segment %s "
+ errmsg("could not write to WAL segment %s "
"at offset %u, length %lu: %m",
xlogfname, startoff, (unsigned long) segbytes)));
}
@@ -1042,7 +1042,7 @@ XLogWalRcvClose(XLogRecPtr recptr, TimeLineID tli)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index 1eb4509fca..a8e8d6f67f 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -837,7 +837,7 @@ PrintNewControlValues(void)
XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID,
newXlogSegNo, WalSegSz);
- printf(_("First log segment after reset: %s\n"), fname);
+ printf(_("First WAL segment after reset: %s\n"), fname);
if (set_mxid != 0)
{
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index 41b8f69b8c..67a964ace4 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -346,7 +346,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
got_mxoff = true;
}
- else if ((p = strstr(bufin, "First log segment after reset:")) != NULL)
+ else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL)
{
/* Skip the colon and any whitespace after it */
p = strchr(p, ':');
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 9ffe9e55bd..7a57f64722 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -831,7 +831,7 @@ usage(void)
printf(_(" -F, --fork=FORK only show records that modify blocks in fork FORK;\n"
" valid names are main, fsm, vm, init\n"));
printf(_(" -n, --limit=N number of records to display\n"));
- printf(_(" -p, --path=PATH directory in which to find log segment files or a\n"
+ printf(_(" -p, --path=PATH directory in which to find WAL segment files or a\n"
" directory with a ./pg_wal that contains such files\n"
" (default: current directory, ./pg_wal, $PGDATA/pg_wal)\n"));
printf(_(" -q, --quiet do not print any output, except for errors\n"));
@@ -839,7 +839,7 @@ usage(void)
" use --rmgr=list to list valid resource manager names\n"));
printf(_(" -R, --relation=T/D/R only show records that modify blocks in relation T/D/R\n"));
printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n"));
- printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ printf(_(" -t, --timeline=TLI timeline from which to read WAL records\n"
" (default: 1 or the value used in STARTSEG)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" -w, --fullpage only show records with a full page write\n"));
--
2.25.1
[application/octet-stream] v3-0002-Replace-log-record-with-WAL-record-in-docs.patch (3.9K, ../../CALj2ACXhKo857tidmzZCU9f4Oxzgu3DDUj=_MOu14Ohjuk=K4A@mail.gmail.com/3-v3-0002-Replace-log-record-with-WAL-record-in-docs.patch)
download | inline diff:
From 0b07cced29ef034107d81c3d4e4560f5a4819c98 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Wed, 2 Mar 2022 06:08:08 +0000
Subject: [PATCH v3] Replace log record with WAL record in docs
---
doc/src/sgml/backup.sgml | 4 ++--
doc/src/sgml/ref/pg_waldump.sgml | 4 ++--
doc/src/sgml/wal.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 0d69851bb1..dd8640b092 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -482,8 +482,8 @@ tar -cf backup.tar /usr/local/pgsql/data
<para>
At all times, <productname>PostgreSQL</productname> maintains a
<firstterm>write ahead log</firstterm> (WAL) in the <filename>pg_wal/</filename>
- subdirectory of the cluster's data directory. The log records
- every change made to the database's data files. This log exists
+ subdirectory of the cluster's data directory. The WAL records
+ capture every change made to the database's data files. This log exists
primarily for crash-safety purposes: if the system crashes, the
database can be restored to consistency by <quote>replaying</quote> the
log entries made since the last checkpoint. However, the existence
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 5735a161ce..8136244502 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -156,7 +156,7 @@ PostgreSQL documentation
<listitem>
<para>
WAL location at which to start reading. The default is to start reading
- the first valid log record found in the earliest file found.
+ the first valid WAL record found in the earliest file found.
</para>
</listitem>
</varlistentry>
@@ -166,7 +166,7 @@ PostgreSQL documentation
<term><option>--timeline=<replaceable>timeline</replaceable></option></term>
<listitem>
<para>
- Timeline from which to read log records. The default is to use the
+ Timeline from which to read WAL records. The default is to use the
value in <replaceable>startseg</replaceable>, if that is specified; otherwise, the
default is 1.
</para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 2bb27a8468..2677996f2a 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -296,12 +296,12 @@
transaction processing. Briefly, <acronym>WAL</acronym>'s central
concept is that changes to data files (where tables and indexes
reside) must be written only after those changes have been logged,
- that is, after log records describing the changes have been flushed
+ that is, after WAL records describing the changes have been flushed
to permanent storage. If we follow this procedure, we do not need
to flush data pages to disk on every transaction commit, because we
know that in the event of a crash we will be able to recover the
database using the log: any changes that have not been applied to
- the data pages can be redone from the log records. (This is
+ the data pages can be redone from the WAL records. (This is
roll-forward recovery, also known as REDO.)
</para>
@@ -838,7 +838,7 @@
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
- <option>--with-wal-blocksize</option> configure option). The log record headers
+ <option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
--
2.25.1
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
@ 2022-03-31 15:45 ` Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Nathan Bossart @ 2022-03-31 15:45 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; PostgreSQL Hackers <[email protected]>
At all times, <productname>PostgreSQL</productname> maintains a
<firstterm>write ahead log</firstterm> (WAL) in the <filename>pg_wal/</filename>
- subdirectory of the cluster's data directory. The log records
- every change made to the database's data files. This log exists
+ subdirectory of the cluster's data directory. The WAL records
+ capture every change made to the database's data files. This log exists
I don't think this change really adds anything. The preceding sentence
makes it clear that we are discussing the write-ahead log, and IMO the
change in phrasing ("the log records every change" is changed to "the
records capture every change") subtly changes the meaning of the sentence.
The rest looks good to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
@ 2022-07-18 10:54 ` Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Bharath Rupireddy @ 2022-07-18 10:54 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Apr 26, 2022 at 1:24 AM Nathan Bossart <[email protected]> wrote:
>
> It's been a few weeks, so I'm marking the commitfest entry as
> waiting-on-author.
Thanks. I'm attaching the updated v4 patches (also subsumed Kyotaro
San's patch at [1]). Please review it further.
[1] https://www.postgresql.org/message-id/20220401.103110.1103213854487561781.horikyota.ntt%40gmail.com
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v4-0001-Use-WAL-segment-instead-of-log-segment.patch (9.0K, ../../CALj2ACUxV-_jzwuYMZXbT=dJHuO2HNUzE67LorhqkSziqNOn+w@mail.gmail.com/2-v4-0001-Use-WAL-segment-instead-of-log-segment.patch)
download | inline diff:
From 68d39c9b087e25fc39312d72cca0ed31c1d9fad2 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Mon, 18 Jul 2022 10:27:20 +0000
Subject: [PATCH v4] Use "WAL segment" instead of "log segment"
We are using "log segment" in various user-facing messages, the
term "log" can mean server logs as well. The "WAL segment" suits
well here and it is consistently used across the other user-facing
messages.
Author: Bharath Rupireddy
---
src/backend/access/transam/xlogreader.c | 10 +++++-----
src/backend/access/transam/xlogrecovery.c | 6 +++---
src/backend/access/transam/xlogutils.c | 4 ++--
src/backend/replication/walreceiver.c | 6 +++---
src/bin/pg_resetwal/pg_resetwal.c | 2 +-
src/bin/pg_upgrade/controldata.c | 2 +-
src/bin/pg_waldump/pg_waldump.c | 4 ++--
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index f3dc4b7797..58f1a32b00 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1209,7 +1209,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid magic number %04X in log segment %s, offset %u",
+ "invalid magic number %04X in WAL segment %s, offset %u",
hdr->xlp_magic,
fname,
offset);
@@ -1223,7 +1223,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1264,7 +1264,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
/* hmm, first page of file doesn't have a long header? */
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1283,7 +1283,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "unexpected pageaddr %X/%X in log segment %s, offset %u",
+ "unexpected pageaddr %X/%X in WAL segment %s, offset %u",
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
@@ -1308,7 +1308,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "out-of-sequence timeline ID %u (after %u) in log segment %s, offset %u",
+ "out-of-sequence timeline ID %u (after %u) in WAL segment %s, offset %u",
hdr->xlp_tli,
state->latestPageTLI,
fname,
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 5d6f1b5e46..306a9f40e9 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -3018,7 +3018,7 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
XLogFileName(fname, xlogreader->seg.ws_tli, segno,
wal_segment_size);
ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg("unexpected timeline ID %u in log segment %s, offset %u",
+ (errmsg("unexpected timeline ID %u in WAL segment %s, offset %u",
xlogreader->latestPageTLI,
fname,
offset)));
@@ -3223,13 +3223,13 @@ retry:
errno = save_errno;
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %u: %m",
+ errmsg("could not read from WAL segment %s, offset %u: %m",
fname, readOff)));
}
else
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %u: read %d of %zu",
+ errmsg("could not read from WAL segment %s, offset %u: read %d of %zu",
fname, readOff, r, (Size) XLOG_BLCKSZ)));
goto next_record_is_invalid;
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 0cda22597f..9e3a000768 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -1049,14 +1049,14 @@ WALReadRaiseError(WALReadError *errinfo)
errno = errinfo->wre_errno;
ereport(ERROR,
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %d: %m",
+ errmsg("could not read from WAL segment %s, offset %d: %m",
fname, errinfo->wre_off)));
}
else if (errinfo->wre_read == 0)
{
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %d: read %d of %d",
+ errmsg("could not read from WAL segment %s, offset %d: read %d of %d",
fname, errinfo->wre_off, errinfo->wre_read,
errinfo->wre_req)));
}
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 3d37c1fe62..3767466ef3 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -616,7 +616,7 @@ WalReceiverMain(void)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
@@ -930,7 +930,7 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr, TimeLineID tli)
errno = save_errno;
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not write to log segment %s "
+ errmsg("could not write to WAL segment %s "
"at offset %u, length %lu: %m",
xlogfname, startoff, (unsigned long) segbytes)));
}
@@ -1042,7 +1042,7 @@ XLogWalRcvClose(XLogRecPtr recptr, TimeLineID tli)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index d4772a2965..7adf79eeed 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -788,7 +788,7 @@ PrintNewControlValues(void)
XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID,
newXlogSegNo, WalSegSz);
- printf(_("First log segment after reset: %s\n"), fname);
+ printf(_("First WAL segment after reset: %s\n"), fname);
if (set_mxid != 0)
{
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index 07de918358..678e8ebf6b 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -350,7 +350,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
got_mxoff = true;
}
- else if ((p = strstr(bufin, "First log segment after reset:")) != NULL)
+ else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL)
{
/* Skip the colon and any whitespace after it */
p = strchr(p, ':');
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 6528113628..4eebeadc8c 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -667,7 +667,7 @@ usage(void)
printf(_(" -F, --fork=FORK only show records that modify blocks in fork FORK;\n"
" valid names are main, fsm, vm, init\n"));
printf(_(" -n, --limit=N number of records to display\n"));
- printf(_(" -p, --path=PATH directory in which to find log segment files or a\n"
+ printf(_(" -p, --path=PATH directory in which to find WAL segment files or a\n"
" directory with a ./pg_wal that contains such files\n"
" (default: current directory, ./pg_wal, $PGDATA/pg_wal)\n"));
printf(_(" -q, --quiet do not print any output, except for errors\n"));
@@ -675,7 +675,7 @@ usage(void)
" use --rmgr=list to list valid resource manager names\n"));
printf(_(" -R, --relation=T/D/R only show records that modify blocks in relation T/D/R\n"));
printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n"));
- printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ printf(_(" -t, --timeline=TLI timeline from which to read WAL records\n"
" (default: 1 or the value used in STARTSEG)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" -w, --fullpage only show records with a full page write\n"));
--
2.25.1
[application/octet-stream] v4-0002-Replace-log-record-with-WAL-record-in-docs.patch (17.3K, ../../CALj2ACUxV-_jzwuYMZXbT=dJHuO2HNUzE67LorhqkSziqNOn+w@mail.gmail.com/3-v4-0002-Replace-log-record-with-WAL-record-in-docs.patch)
download | inline diff:
From 654984e6ee83de08a800ac4f49a67b9c2d13fe27 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Mon, 18 Jul 2022 10:48:52 +0000
Subject: [PATCH v4] Replace log record with WAL record in docs
Authors: Kyotaro Horiguchi, Bharath Rupireddy
---
doc/src/sgml/backup.sgml | 14 ++++----
doc/src/sgml/ref/pg_waldump.sgml | 10 +++---
doc/src/sgml/wal.sgml | 60 ++++++++++++++++----------------
3 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 73a774d3d7..cc5ae59ac2 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1095,7 +1095,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
require that you have enough free space on your system to hold two
copies of your existing database. If you do not have enough space,
you should at least save the contents of the cluster's <filename>pg_wal</filename>
- subdirectory, as it might contain logs which
+ subdirectory, as it might contain WAL files which
were not archived before the system went down.
</para>
</listitem>
@@ -1173,8 +1173,8 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
which tells <productname>PostgreSQL</productname> how to retrieve archived
WAL file segments. Like the <varname>archive_command</varname>, this is
a shell command string. It can contain <literal>%f</literal>, which is
- replaced by the name of the desired log file, and <literal>%p</literal>,
- which is replaced by the path name to copy the log file to.
+ replaced by the name of the desired WAL file, and <literal>%p</literal>,
+ which is replaced by the path name to copy the WAL file to.
(The path name is relative to the current working directory,
i.e., the cluster's data directory.)
Write <literal>%%</literal> if you need to embed an actual <literal>%</literal>
@@ -1462,9 +1462,9 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
commands are WAL-logged with the literal absolute path, and will
therefore be replayed as tablespace creations with the same
- absolute path. This might be undesirable if the log is being
+ absolute path. This might be undesirable if the WAL is being
replayed on a different machine. It can be dangerous even if the
- log is being replayed on the same machine, but into a new data
+ WAL is being replayed on the same machine, but into a new data
directory: the replay will still overwrite the contents of the
original tablespace. To avoid potential gotchas of this sort,
the best practice is to take a new base backup after creating or
@@ -1481,11 +1481,11 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
we might need to fix partially-written disk pages. Depending on
your system hardware and software, the risk of partial writes might
be small enough to ignore, in which case you can significantly
- reduce the total volume of archived logs by turning off page
+ reduce the total volume of archived WAL files by turning off page
snapshots using the <xref linkend="guc-full-page-writes"/>
parameter. (Read the notes and warnings in <xref linkend="wal"/>
before you do so.) Turning off page snapshots does not prevent
- use of the logs for PITR operations. An area for future
+ use of the WAL for PITR operations. An area for future
development is to compress archived WAL data by removing
unnecessary page copies even when <varname>full_page_writes</varname> is
on. In the meantime, administrators might wish to reduce the number
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 57746d9421..2e2166bb6f 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -53,7 +53,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">startseg</replaceable></term>
<listitem>
<para>
- Start reading at the specified log segment file. This implicitly determines
+ Start reading at the specified WAL segment file. This implicitly determines
the path in which files will be searched for, and the timeline to use.
</para>
</listitem>
@@ -63,7 +63,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">endseg</replaceable></term>
<listitem>
<para>
- Stop after reading the specified log segment file.
+ Stop after reading the specified WAL segment file.
</para>
</listitem>
</varlistentry>
@@ -141,7 +141,7 @@ PostgreSQL documentation
<term><option>--path=<replaceable>path</replaceable></option></term>
<listitem>
<para>
- Specifies a directory to search for log segment files or a
+ Specifies a directory to search for WAL segment files or a
directory with a <literal>pg_wal</literal> subdirectory that
contains such files. The default is to search in the current
directory, the <literal>pg_wal</literal> subdirectory of the
@@ -203,7 +203,7 @@ PostgreSQL documentation
<listitem>
<para>
WAL location at which to start reading. The default is to start reading
- the first valid log record found in the earliest file found.
+ the first valid WAL record found in the earliest file found.
</para>
</listitem>
</varlistentry>
@@ -213,7 +213,7 @@ PostgreSQL documentation
<term><option>--timeline=<replaceable>timeline</replaceable></option></term>
<listitem>
<para>
- Timeline from which to read log records. The default is to use the
+ Timeline from which to read WAL records. The default is to use the
value in <replaceable>startseg</replaceable>, if that is specified; otherwise, the
default is 1.
</para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 4b6ef283c1..e8bd7ffecf 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -296,12 +296,12 @@
transaction processing. Briefly, <acronym>WAL</acronym>'s central
concept is that changes to data files (where tables and indexes
reside) must be written only after those changes have been logged,
- that is, after log records describing the changes have been flushed
+ that is, after WAL records describing the changes have been flushed
to permanent storage. If we follow this procedure, we do not need
to flush data pages to disk on every transaction commit, because we
know that in the event of a crash we will be able to recover the
database using the log: any changes that have not been applied to
- the data pages can be redone from the log records. (This is
+ the data pages can be redone from the WAL records. (This is
roll-forward recovery, also known as REDO.)
</para>
@@ -322,15 +322,15 @@
<para>
Using <acronym>WAL</acronym> results in a
- significantly reduced number of disk writes, because only the log
+ significantly reduced number of disk writes, because only the WAL
file needs to be flushed to disk to guarantee that a transaction is
committed, rather than every data file changed by the transaction.
- The log file is written sequentially,
- and so the cost of syncing the log is much less than the cost of
+ The WAL file is written sequentially,
+ and so the cost of syncing the WAL is much less than the cost of
flushing the data pages. This is especially true for servers
handling many small transactions touching different parts of the data
store. Furthermore, when the server is processing many small concurrent
- transactions, one <function>fsync</function> of the log file may
+ transactions, one <function>fsync</function> of the WAL file may
suffice to commit many transactions.
</para>
@@ -340,10 +340,10 @@
linkend="continuous-archiving"/>. By archiving the WAL data we can support
reverting to any time instant covered by the available WAL data:
we simply install a prior physical backup of the database, and
- replay the WAL log just as far as the desired time. What's more,
+ replay the WAL just as far as the desired time. What's more,
the physical backup doesn't have to be an instantaneous snapshot
of the database state — if it is made over some period of time,
- then replaying the WAL log for that period will fix any internal
+ then replaying the WAL for that period will fix any internal
inconsistencies.
</para>
</sect1>
@@ -496,15 +496,15 @@
that the heap and index data files have been updated with all
information written before that checkpoint. At checkpoint time, all
dirty data pages are flushed to disk and a special checkpoint record is
- written to the log file. (The change records were previously flushed
+ written to the WAL file. (The change records were previously flushed
to the <acronym>WAL</acronym> files.)
In the event of a crash, the crash recovery procedure looks at the latest
- checkpoint record to determine the point in the log (known as the redo
+ checkpoint record to determine the point in the WAL (known as the redo
record) from which it should start the REDO operation. Any changes made to
data files before that point are guaranteed to be already on disk.
- Hence, after a checkpoint, log segments preceding the one containing
+ Hence, after a checkpoint, WAL segments preceding the one containing
the redo record are no longer needed and can be recycled or removed. (When
- <acronym>WAL</acronym> archiving is being done, the log segments must be
+ <acronym>WAL</acronym> archiving is being done, the WAL segments must be
archived before being recycled or removed.)
</para>
@@ -543,7 +543,7 @@
another factor to consider. To ensure data page consistency,
the first modification of a data page after each checkpoint results in
logging the entire page content. In that case,
- a smaller checkpoint interval increases the volume of output to the WAL log,
+ a smaller checkpoint interval increases the volume of output to the WAL,
partially negating the goal of using a smaller interval,
and in any case causing more disk I/O.
</para>
@@ -613,10 +613,10 @@
<para>
The number of WAL segment files in <filename>pg_wal</filename> directory depends on
<varname>min_wal_size</varname>, <varname>max_wal_size</varname> and
- the amount of WAL generated in previous checkpoint cycles. When old log
+ the amount of WAL generated in previous checkpoint cycles. When old WAL
segment files are no longer needed, they are removed or recycled (that is,
renamed to become future segments in the numbered sequence). If, due to a
- short-term peak of log output rate, <varname>max_wal_size</varname> is
+ short-term peak of WAL output rate, <varname>max_wal_size</varname> is
exceeded, the unneeded segment files will be removed until the system
gets back under this limit. Below that limit, the system recycles enough
WAL files to cover the estimated need until the next checkpoint, and
@@ -649,7 +649,7 @@
which are similar to checkpoints in normal operation: the server forces
all its state to disk, updates the <filename>pg_control</filename> file to
indicate that the already-processed WAL data need not be scanned again,
- and then recycles any old log segment files in the <filename>pg_wal</filename>
+ and then recycles any old WAL segment files in the <filename>pg_wal</filename>
directory.
Restartpoints can't be performed more frequently than checkpoints on the
primary because restartpoints can only be performed at checkpoint records.
@@ -675,12 +675,12 @@
insertion) at a time when an exclusive lock is held on affected
data pages, so the operation needs to be as fast as possible. What
is worse, writing <acronym>WAL</acronym> buffers might also force the
- creation of a new log segment, which takes even more
+ creation of a new WAL segment, which takes even more
time. Normally, <acronym>WAL</acronym> buffers should be written
and flushed by an <function>XLogFlush</function> request, which is
made, for the most part, at transaction commit time to ensure that
transaction records are flushed to permanent storage. On systems
- with high log output, <function>XLogFlush</function> requests might
+ with high WAL output, <function>XLogFlush</function> requests might
not occur often enough to prevent <function>XLogInsertRecord</function>
from having to do writes. On such systems
one should increase the number of <acronym>WAL</acronym> buffers by
@@ -723,7 +723,7 @@
<varname>commit_delay</varname>, so this value is recommended as the
starting point to use when optimizing for a particular workload. While
tuning <varname>commit_delay</varname> is particularly useful when the
- WAL log is stored on high-latency rotating disks, benefits can be
+ WAL is stored on high-latency rotating disks, benefits can be
significant even on storage media with very fast sync times, such as
solid-state drives or RAID arrays with a battery-backed write cache;
but this should definitely be tested against a representative workload.
@@ -827,16 +827,16 @@
<para>
<acronym>WAL</acronym> is automatically enabled; no action is
required from the administrator except ensuring that the
- disk-space requirements for the <acronym>WAL</acronym> logs are met,
+ disk-space requirements for the <acronym>WAL</acronym> files are met,
and that any necessary tuning is done (see <xref
linkend="wal-configuration"/>).
</para>
<para>
<acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
- logs as each new record is written. The insert position is described by
+ files as each new record is written. The insert position is described by
a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
- the logs, increasing monotonically with each new record.
+ the WAL, increasing monotonically with each new record.
<acronym>LSN</acronym> values are returned as the datatype
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
compared to calculate the volume of <acronym>WAL</acronym> data that
@@ -845,12 +845,12 @@
</para>
<para>
- <acronym>WAL</acronym> logs are stored in the directory
+ <acronym>WAL</acronym> files are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
- <option>--with-wal-blocksize</option> configure option). The log record headers
+ <option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
@@ -860,7 +860,7 @@
</para>
<para>
- It is advantageous if the log is located on a different disk from the
+ It is advantageous if the WAL is located on a different disk from the
main database files. This can be achieved by moving the
<filename>pg_wal</filename> directory to another location (while the server
is shut down, of course) and creating a symbolic link from the
@@ -876,19 +876,19 @@
on the disk. A power failure in such a situation might lead to
irrecoverable data corruption. Administrators should try to ensure
that disks holding <productname>PostgreSQL</productname>'s
- <acronym>WAL</acronym> log files do not make such false reports.
+ <acronym>WAL</acronym> files do not make such false reports.
(See <xref linkend="wal-reliability"/>.)
</para>
<para>
- After a checkpoint has been made and the log flushed, the
+ After a checkpoint has been made and the WAL flushed, the
checkpoint's position is saved in the file
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
- scanning forward from the log location indicated in the checkpoint
+ scanning forward from the WAL location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
- log on the first page modification after a checkpoint (assuming
+ WAL record on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"/> is not disabled), all pages
changed since the checkpoint will be restored to a consistent
state.
@@ -896,7 +896,7 @@
<para>
To deal with the case where <filename>pg_control</filename> is
- corrupt, we should support the possibility of scanning existing log
+ corrupt, we should support the possibility of scanning existing WAL
segments in reverse order — newest to oldest — in order to find the
latest checkpoint. This has not been implemented yet.
<filename>pg_control</filename> is small enough (less than one disk page)
--
2.25.1
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
@ 2022-07-18 18:30 ` Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Nathan Bossart @ 2022-07-18 18:30 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; PostgreSQL Hackers <[email protected]>
Overall, these patches look reasonable.
On Mon, Jul 18, 2022 at 04:24:12PM +0530, Bharath Rupireddy wrote:
> record. Because the entire content of data pages is saved in the
> - log on the first page modification after a checkpoint (assuming
> + WAL record on the first page modification after a checkpoint (assuming
> <xref linkend="guc-full-page-writes"/> is not disabled), all pages
> changed since the checkpoint will be restored to a consistent
> state.
nitpick: I would remove the word "record" in this change.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
@ 2022-07-19 09:13 ` Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Bharath Rupireddy @ 2022-07-19 09:13 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Jul 19, 2022 at 12:00 AM Nathan Bossart
<[email protected]> wrote:
>
> Overall, these patches look reasonable.
>
> On Mon, Jul 18, 2022 at 04:24:12PM +0530, Bharath Rupireddy wrote:
> > record. Because the entire content of data pages is saved in the
> > - log on the first page modification after a checkpoint (assuming
> > + WAL record on the first page modification after a checkpoint (assuming
> > <xref linkend="guc-full-page-writes"/> is not disabled), all pages
> > changed since the checkpoint will be restored to a consistent
> > state.
>
> nitpick: I would remove the word "record" in this change.
Done. PSA v5 patch set.
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v5-0001-Use-WAL-segment-instead-of-log-segment.patch (9.0K, ../../CALj2ACVTtH9HamzzYTSFuEopeh77homm3mW2fx13QPnsnGAKUg@mail.gmail.com/2-v5-0001-Use-WAL-segment-instead-of-log-segment.patch)
download | inline diff:
From 68d39c9b087e25fc39312d72cca0ed31c1d9fad2 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Mon, 18 Jul 2022 10:27:20 +0000
Subject: [PATCH v5] Use "WAL segment" instead of "log segment"
We are using "log segment" in various user-facing messages, the
term "log" can mean server logs as well. The "WAL segment" suits
well here and it is consistently used across the other user-facing
messages.
Author: Bharath Rupireddy
---
src/backend/access/transam/xlogreader.c | 10 +++++-----
src/backend/access/transam/xlogrecovery.c | 6 +++---
src/backend/access/transam/xlogutils.c | 4 ++--
src/backend/replication/walreceiver.c | 6 +++---
src/bin/pg_resetwal/pg_resetwal.c | 2 +-
src/bin/pg_upgrade/controldata.c | 2 +-
src/bin/pg_waldump/pg_waldump.c | 4 ++--
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index f3dc4b7797..58f1a32b00 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1209,7 +1209,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid magic number %04X in log segment %s, offset %u",
+ "invalid magic number %04X in WAL segment %s, offset %u",
hdr->xlp_magic,
fname,
offset);
@@ -1223,7 +1223,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1264,7 +1264,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
/* hmm, first page of file doesn't have a long header? */
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1283,7 +1283,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "unexpected pageaddr %X/%X in log segment %s, offset %u",
+ "unexpected pageaddr %X/%X in WAL segment %s, offset %u",
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
@@ -1308,7 +1308,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "out-of-sequence timeline ID %u (after %u) in log segment %s, offset %u",
+ "out-of-sequence timeline ID %u (after %u) in WAL segment %s, offset %u",
hdr->xlp_tli,
state->latestPageTLI,
fname,
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 5d6f1b5e46..306a9f40e9 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -3018,7 +3018,7 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
XLogFileName(fname, xlogreader->seg.ws_tli, segno,
wal_segment_size);
ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg("unexpected timeline ID %u in log segment %s, offset %u",
+ (errmsg("unexpected timeline ID %u in WAL segment %s, offset %u",
xlogreader->latestPageTLI,
fname,
offset)));
@@ -3223,13 +3223,13 @@ retry:
errno = save_errno;
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %u: %m",
+ errmsg("could not read from WAL segment %s, offset %u: %m",
fname, readOff)));
}
else
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %u: read %d of %zu",
+ errmsg("could not read from WAL segment %s, offset %u: read %d of %zu",
fname, readOff, r, (Size) XLOG_BLCKSZ)));
goto next_record_is_invalid;
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 0cda22597f..9e3a000768 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -1049,14 +1049,14 @@ WALReadRaiseError(WALReadError *errinfo)
errno = errinfo->wre_errno;
ereport(ERROR,
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %d: %m",
+ errmsg("could not read from WAL segment %s, offset %d: %m",
fname, errinfo->wre_off)));
}
else if (errinfo->wre_read == 0)
{
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %d: read %d of %d",
+ errmsg("could not read from WAL segment %s, offset %d: read %d of %d",
fname, errinfo->wre_off, errinfo->wre_read,
errinfo->wre_req)));
}
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 3d37c1fe62..3767466ef3 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -616,7 +616,7 @@ WalReceiverMain(void)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
@@ -930,7 +930,7 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr, TimeLineID tli)
errno = save_errno;
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not write to log segment %s "
+ errmsg("could not write to WAL segment %s "
"at offset %u, length %lu: %m",
xlogfname, startoff, (unsigned long) segbytes)));
}
@@ -1042,7 +1042,7 @@ XLogWalRcvClose(XLogRecPtr recptr, TimeLineID tli)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index d4772a2965..7adf79eeed 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -788,7 +788,7 @@ PrintNewControlValues(void)
XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID,
newXlogSegNo, WalSegSz);
- printf(_("First log segment after reset: %s\n"), fname);
+ printf(_("First WAL segment after reset: %s\n"), fname);
if (set_mxid != 0)
{
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index 07de918358..678e8ebf6b 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -350,7 +350,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
got_mxoff = true;
}
- else if ((p = strstr(bufin, "First log segment after reset:")) != NULL)
+ else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL)
{
/* Skip the colon and any whitespace after it */
p = strchr(p, ':');
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 6528113628..4eebeadc8c 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -667,7 +667,7 @@ usage(void)
printf(_(" -F, --fork=FORK only show records that modify blocks in fork FORK;\n"
" valid names are main, fsm, vm, init\n"));
printf(_(" -n, --limit=N number of records to display\n"));
- printf(_(" -p, --path=PATH directory in which to find log segment files or a\n"
+ printf(_(" -p, --path=PATH directory in which to find WAL segment files or a\n"
" directory with a ./pg_wal that contains such files\n"
" (default: current directory, ./pg_wal, $PGDATA/pg_wal)\n"));
printf(_(" -q, --quiet do not print any output, except for errors\n"));
@@ -675,7 +675,7 @@ usage(void)
" use --rmgr=list to list valid resource manager names\n"));
printf(_(" -R, --relation=T/D/R only show records that modify blocks in relation T/D/R\n"));
printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n"));
- printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ printf(_(" -t, --timeline=TLI timeline from which to read WAL records\n"
" (default: 1 or the value used in STARTSEG)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" -w, --fullpage only show records with a full page write\n"));
--
2.25.1
[application/octet-stream] v5-0002-Replace-log-record-with-WAL-record-in-docs.patch (17.2K, ../../CALj2ACVTtH9HamzzYTSFuEopeh77homm3mW2fx13QPnsnGAKUg@mail.gmail.com/3-v5-0002-Replace-log-record-with-WAL-record-in-docs.patch)
download | inline diff:
From 8657cf222102cd6f15ee773c6301ed41be2831eb Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Tue, 19 Jul 2022 09:12:12 +0000
Subject: [PATCH v5] Replace log record with WAL record in docs
Authors: Kyotaro Horiguchi, Bharath Rupireddy
---
doc/src/sgml/backup.sgml | 14 ++++----
doc/src/sgml/ref/pg_waldump.sgml | 10 +++---
doc/src/sgml/wal.sgml | 60 ++++++++++++++++----------------
3 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 73a774d3d7..cc5ae59ac2 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1095,7 +1095,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
require that you have enough free space on your system to hold two
copies of your existing database. If you do not have enough space,
you should at least save the contents of the cluster's <filename>pg_wal</filename>
- subdirectory, as it might contain logs which
+ subdirectory, as it might contain WAL files which
were not archived before the system went down.
</para>
</listitem>
@@ -1173,8 +1173,8 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
which tells <productname>PostgreSQL</productname> how to retrieve archived
WAL file segments. Like the <varname>archive_command</varname>, this is
a shell command string. It can contain <literal>%f</literal>, which is
- replaced by the name of the desired log file, and <literal>%p</literal>,
- which is replaced by the path name to copy the log file to.
+ replaced by the name of the desired WAL file, and <literal>%p</literal>,
+ which is replaced by the path name to copy the WAL file to.
(The path name is relative to the current working directory,
i.e., the cluster's data directory.)
Write <literal>%%</literal> if you need to embed an actual <literal>%</literal>
@@ -1462,9 +1462,9 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
commands are WAL-logged with the literal absolute path, and will
therefore be replayed as tablespace creations with the same
- absolute path. This might be undesirable if the log is being
+ absolute path. This might be undesirable if the WAL is being
replayed on a different machine. It can be dangerous even if the
- log is being replayed on the same machine, but into a new data
+ WAL is being replayed on the same machine, but into a new data
directory: the replay will still overwrite the contents of the
original tablespace. To avoid potential gotchas of this sort,
the best practice is to take a new base backup after creating or
@@ -1481,11 +1481,11 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
we might need to fix partially-written disk pages. Depending on
your system hardware and software, the risk of partial writes might
be small enough to ignore, in which case you can significantly
- reduce the total volume of archived logs by turning off page
+ reduce the total volume of archived WAL files by turning off page
snapshots using the <xref linkend="guc-full-page-writes"/>
parameter. (Read the notes and warnings in <xref linkend="wal"/>
before you do so.) Turning off page snapshots does not prevent
- use of the logs for PITR operations. An area for future
+ use of the WAL for PITR operations. An area for future
development is to compress archived WAL data by removing
unnecessary page copies even when <varname>full_page_writes</varname> is
on. In the meantime, administrators might wish to reduce the number
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 57746d9421..2e2166bb6f 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -53,7 +53,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">startseg</replaceable></term>
<listitem>
<para>
- Start reading at the specified log segment file. This implicitly determines
+ Start reading at the specified WAL segment file. This implicitly determines
the path in which files will be searched for, and the timeline to use.
</para>
</listitem>
@@ -63,7 +63,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">endseg</replaceable></term>
<listitem>
<para>
- Stop after reading the specified log segment file.
+ Stop after reading the specified WAL segment file.
</para>
</listitem>
</varlistentry>
@@ -141,7 +141,7 @@ PostgreSQL documentation
<term><option>--path=<replaceable>path</replaceable></option></term>
<listitem>
<para>
- Specifies a directory to search for log segment files or a
+ Specifies a directory to search for WAL segment files or a
directory with a <literal>pg_wal</literal> subdirectory that
contains such files. The default is to search in the current
directory, the <literal>pg_wal</literal> subdirectory of the
@@ -203,7 +203,7 @@ PostgreSQL documentation
<listitem>
<para>
WAL location at which to start reading. The default is to start reading
- the first valid log record found in the earliest file found.
+ the first valid WAL record found in the earliest file found.
</para>
</listitem>
</varlistentry>
@@ -213,7 +213,7 @@ PostgreSQL documentation
<term><option>--timeline=<replaceable>timeline</replaceable></option></term>
<listitem>
<para>
- Timeline from which to read log records. The default is to use the
+ Timeline from which to read WAL records. The default is to use the
value in <replaceable>startseg</replaceable>, if that is specified; otherwise, the
default is 1.
</para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 4b6ef283c1..315ce5f8bd 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -296,12 +296,12 @@
transaction processing. Briefly, <acronym>WAL</acronym>'s central
concept is that changes to data files (where tables and indexes
reside) must be written only after those changes have been logged,
- that is, after log records describing the changes have been flushed
+ that is, after WAL records describing the changes have been flushed
to permanent storage. If we follow this procedure, we do not need
to flush data pages to disk on every transaction commit, because we
know that in the event of a crash we will be able to recover the
database using the log: any changes that have not been applied to
- the data pages can be redone from the log records. (This is
+ the data pages can be redone from the WAL records. (This is
roll-forward recovery, also known as REDO.)
</para>
@@ -322,15 +322,15 @@
<para>
Using <acronym>WAL</acronym> results in a
- significantly reduced number of disk writes, because only the log
+ significantly reduced number of disk writes, because only the WAL
file needs to be flushed to disk to guarantee that a transaction is
committed, rather than every data file changed by the transaction.
- The log file is written sequentially,
- and so the cost of syncing the log is much less than the cost of
+ The WAL file is written sequentially,
+ and so the cost of syncing the WAL is much less than the cost of
flushing the data pages. This is especially true for servers
handling many small transactions touching different parts of the data
store. Furthermore, when the server is processing many small concurrent
- transactions, one <function>fsync</function> of the log file may
+ transactions, one <function>fsync</function> of the WAL file may
suffice to commit many transactions.
</para>
@@ -340,10 +340,10 @@
linkend="continuous-archiving"/>. By archiving the WAL data we can support
reverting to any time instant covered by the available WAL data:
we simply install a prior physical backup of the database, and
- replay the WAL log just as far as the desired time. What's more,
+ replay the WAL just as far as the desired time. What's more,
the physical backup doesn't have to be an instantaneous snapshot
of the database state — if it is made over some period of time,
- then replaying the WAL log for that period will fix any internal
+ then replaying the WAL for that period will fix any internal
inconsistencies.
</para>
</sect1>
@@ -496,15 +496,15 @@
that the heap and index data files have been updated with all
information written before that checkpoint. At checkpoint time, all
dirty data pages are flushed to disk and a special checkpoint record is
- written to the log file. (The change records were previously flushed
+ written to the WAL file. (The change records were previously flushed
to the <acronym>WAL</acronym> files.)
In the event of a crash, the crash recovery procedure looks at the latest
- checkpoint record to determine the point in the log (known as the redo
+ checkpoint record to determine the point in the WAL (known as the redo
record) from which it should start the REDO operation. Any changes made to
data files before that point are guaranteed to be already on disk.
- Hence, after a checkpoint, log segments preceding the one containing
+ Hence, after a checkpoint, WAL segments preceding the one containing
the redo record are no longer needed and can be recycled or removed. (When
- <acronym>WAL</acronym> archiving is being done, the log segments must be
+ <acronym>WAL</acronym> archiving is being done, the WAL segments must be
archived before being recycled or removed.)
</para>
@@ -543,7 +543,7 @@
another factor to consider. To ensure data page consistency,
the first modification of a data page after each checkpoint results in
logging the entire page content. In that case,
- a smaller checkpoint interval increases the volume of output to the WAL log,
+ a smaller checkpoint interval increases the volume of output to the WAL,
partially negating the goal of using a smaller interval,
and in any case causing more disk I/O.
</para>
@@ -613,10 +613,10 @@
<para>
The number of WAL segment files in <filename>pg_wal</filename> directory depends on
<varname>min_wal_size</varname>, <varname>max_wal_size</varname> and
- the amount of WAL generated in previous checkpoint cycles. When old log
+ the amount of WAL generated in previous checkpoint cycles. When old WAL
segment files are no longer needed, they are removed or recycled (that is,
renamed to become future segments in the numbered sequence). If, due to a
- short-term peak of log output rate, <varname>max_wal_size</varname> is
+ short-term peak of WAL output rate, <varname>max_wal_size</varname> is
exceeded, the unneeded segment files will be removed until the system
gets back under this limit. Below that limit, the system recycles enough
WAL files to cover the estimated need until the next checkpoint, and
@@ -649,7 +649,7 @@
which are similar to checkpoints in normal operation: the server forces
all its state to disk, updates the <filename>pg_control</filename> file to
indicate that the already-processed WAL data need not be scanned again,
- and then recycles any old log segment files in the <filename>pg_wal</filename>
+ and then recycles any old WAL segment files in the <filename>pg_wal</filename>
directory.
Restartpoints can't be performed more frequently than checkpoints on the
primary because restartpoints can only be performed at checkpoint records.
@@ -675,12 +675,12 @@
insertion) at a time when an exclusive lock is held on affected
data pages, so the operation needs to be as fast as possible. What
is worse, writing <acronym>WAL</acronym> buffers might also force the
- creation of a new log segment, which takes even more
+ creation of a new WAL segment, which takes even more
time. Normally, <acronym>WAL</acronym> buffers should be written
and flushed by an <function>XLogFlush</function> request, which is
made, for the most part, at transaction commit time to ensure that
transaction records are flushed to permanent storage. On systems
- with high log output, <function>XLogFlush</function> requests might
+ with high WAL output, <function>XLogFlush</function> requests might
not occur often enough to prevent <function>XLogInsertRecord</function>
from having to do writes. On such systems
one should increase the number of <acronym>WAL</acronym> buffers by
@@ -723,7 +723,7 @@
<varname>commit_delay</varname>, so this value is recommended as the
starting point to use when optimizing for a particular workload. While
tuning <varname>commit_delay</varname> is particularly useful when the
- WAL log is stored on high-latency rotating disks, benefits can be
+ WAL is stored on high-latency rotating disks, benefits can be
significant even on storage media with very fast sync times, such as
solid-state drives or RAID arrays with a battery-backed write cache;
but this should definitely be tested against a representative workload.
@@ -827,16 +827,16 @@
<para>
<acronym>WAL</acronym> is automatically enabled; no action is
required from the administrator except ensuring that the
- disk-space requirements for the <acronym>WAL</acronym> logs are met,
+ disk-space requirements for the <acronym>WAL</acronym> files are met,
and that any necessary tuning is done (see <xref
linkend="wal-configuration"/>).
</para>
<para>
<acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
- logs as each new record is written. The insert position is described by
+ files as each new record is written. The insert position is described by
a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
- the logs, increasing monotonically with each new record.
+ the WAL, increasing monotonically with each new record.
<acronym>LSN</acronym> values are returned as the datatype
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
compared to calculate the volume of <acronym>WAL</acronym> data that
@@ -845,12 +845,12 @@
</para>
<para>
- <acronym>WAL</acronym> logs are stored in the directory
+ <acronym>WAL</acronym> files are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
- <option>--with-wal-blocksize</option> configure option). The log record headers
+ <option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
@@ -860,7 +860,7 @@
</para>
<para>
- It is advantageous if the log is located on a different disk from the
+ It is advantageous if the WAL is located on a different disk from the
main database files. This can be achieved by moving the
<filename>pg_wal</filename> directory to another location (while the server
is shut down, of course) and creating a symbolic link from the
@@ -876,19 +876,19 @@
on the disk. A power failure in such a situation might lead to
irrecoverable data corruption. Administrators should try to ensure
that disks holding <productname>PostgreSQL</productname>'s
- <acronym>WAL</acronym> log files do not make such false reports.
+ <acronym>WAL</acronym> files do not make such false reports.
(See <xref linkend="wal-reliability"/>.)
</para>
<para>
- After a checkpoint has been made and the log flushed, the
+ After a checkpoint has been made and the WAL flushed, the
checkpoint's position is saved in the file
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
- scanning forward from the log location indicated in the checkpoint
+ scanning forward from the WAL location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
- log on the first page modification after a checkpoint (assuming
+ WAL on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"/> is not disabled), all pages
changed since the checkpoint will be restored to a consistent
state.
@@ -896,7 +896,7 @@
<para>
To deal with the case where <filename>pg_control</filename> is
- corrupt, we should support the possibility of scanning existing log
+ corrupt, we should support the possibility of scanning existing WAL
segments in reverse order — newest to oldest — in order to find the
latest checkpoint. This has not been implemented yet.
<filename>pg_control</filename> is small enough (less than one disk page)
--
2.25.1
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
@ 2022-07-19 16:58 ` Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Nathan Bossart @ 2022-07-19 16:58 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Jul 19, 2022 at 02:43:59PM +0530, Bharath Rupireddy wrote:
> Done. PSA v5 patch set.
LGTM. I've marked this as ready-for-committer.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
@ 2022-07-20 01:25 ` Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Kyotaro Horiguchi @ 2022-07-20 01:25 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]
At Tue, 19 Jul 2022 09:58:28 -0700, Nathan Bossart <[email protected]> wrote in
> On Tue, Jul 19, 2022 at 02:43:59PM +0530, Bharath Rupireddy wrote:
> > Done. PSA v5 patch set.
>
> LGTM. I've marked this as ready-for-committer.
I find the following sentense in config.sgml. "Specifies the minimum
size of past log file segments kept in the pg_wal directory"
postgresql.conf.sample contains "logfile segment" in a few lines.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
@ 2022-07-20 04:32 ` Bharath Rupireddy <[email protected]>
2022-07-20 07:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Bharath Rupireddy @ 2022-07-20 04:32 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: Nathan Bossart <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 20, 2022 at 6:55 AM Kyotaro Horiguchi
<[email protected]> wrote:
>
> At Tue, 19 Jul 2022 09:58:28 -0700, Nathan Bossart <[email protected]> wrote in
> > On Tue, Jul 19, 2022 at 02:43:59PM +0530, Bharath Rupireddy wrote:
> > > Done. PSA v5 patch set.
> >
> > LGTM. I've marked this as ready-for-committer.
>
> I find the following sentense in config.sgml. "Specifies the minimum
> size of past log file segments kept in the pg_wal directory"
>
> postgresql.conf.sample contains "logfile segment" in a few lines.
Done. PSA v6 patch set.
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v6-0001-Use-WAL-segment-instead-of-log-segment.patch (9.0K, ../../CALj2ACV0ux_AeCV-xJkA6rbmsdN8KTHGOCx8vJCAa=DEtmgqaA@mail.gmail.com/2-v6-0001-Use-WAL-segment-instead-of-log-segment.patch)
download | inline diff:
From 6094c80f28c64904ede361672521be6b86993adb Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Wed, 20 Jul 2022 04:25:10 +0000
Subject: [PATCH v6] Use "WAL segment" instead of "log segment"
We are using "log segment" in various user-facing messages, the
term "log" can mean server logs as well. The "WAL segment" suits
well here and it is consistently used across the other user-facing
messages.
Author: Bharath Rupireddy
---
src/backend/access/transam/xlogreader.c | 10 +++++-----
src/backend/access/transam/xlogrecovery.c | 6 +++---
src/backend/access/transam/xlogutils.c | 4 ++--
src/backend/replication/walreceiver.c | 6 +++---
src/bin/pg_resetwal/pg_resetwal.c | 2 +-
src/bin/pg_upgrade/controldata.c | 2 +-
src/bin/pg_waldump/pg_waldump.c | 4 ++--
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index f3dc4b7797..58f1a32b00 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1209,7 +1209,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid magic number %04X in log segment %s, offset %u",
+ "invalid magic number %04X in WAL segment %s, offset %u",
hdr->xlp_magic,
fname,
offset);
@@ -1223,7 +1223,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1264,7 +1264,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
/* hmm, first page of file doesn't have a long header? */
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1283,7 +1283,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "unexpected pageaddr %X/%X in log segment %s, offset %u",
+ "unexpected pageaddr %X/%X in WAL segment %s, offset %u",
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
@@ -1308,7 +1308,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "out-of-sequence timeline ID %u (after %u) in log segment %s, offset %u",
+ "out-of-sequence timeline ID %u (after %u) in WAL segment %s, offset %u",
hdr->xlp_tli,
state->latestPageTLI,
fname,
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 5d6f1b5e46..306a9f40e9 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -3018,7 +3018,7 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
XLogFileName(fname, xlogreader->seg.ws_tli, segno,
wal_segment_size);
ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg("unexpected timeline ID %u in log segment %s, offset %u",
+ (errmsg("unexpected timeline ID %u in WAL segment %s, offset %u",
xlogreader->latestPageTLI,
fname,
offset)));
@@ -3223,13 +3223,13 @@ retry:
errno = save_errno;
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %u: %m",
+ errmsg("could not read from WAL segment %s, offset %u: %m",
fname, readOff)));
}
else
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %u: read %d of %zu",
+ errmsg("could not read from WAL segment %s, offset %u: read %d of %zu",
fname, readOff, r, (Size) XLOG_BLCKSZ)));
goto next_record_is_invalid;
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 0cda22597f..9e3a000768 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -1049,14 +1049,14 @@ WALReadRaiseError(WALReadError *errinfo)
errno = errinfo->wre_errno;
ereport(ERROR,
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %d: %m",
+ errmsg("could not read from WAL segment %s, offset %d: %m",
fname, errinfo->wre_off)));
}
else if (errinfo->wre_read == 0)
{
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %d: read %d of %d",
+ errmsg("could not read from WAL segment %s, offset %d: read %d of %d",
fname, errinfo->wre_off, errinfo->wre_read,
errinfo->wre_req)));
}
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 3d37c1fe62..3767466ef3 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -616,7 +616,7 @@ WalReceiverMain(void)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
@@ -930,7 +930,7 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr, TimeLineID tli)
errno = save_errno;
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not write to log segment %s "
+ errmsg("could not write to WAL segment %s "
"at offset %u, length %lu: %m",
xlogfname, startoff, (unsigned long) segbytes)));
}
@@ -1042,7 +1042,7 @@ XLogWalRcvClose(XLogRecPtr recptr, TimeLineID tli)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index d4772a2965..7adf79eeed 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -788,7 +788,7 @@ PrintNewControlValues(void)
XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID,
newXlogSegNo, WalSegSz);
- printf(_("First log segment after reset: %s\n"), fname);
+ printf(_("First WAL segment after reset: %s\n"), fname);
if (set_mxid != 0)
{
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index 07de918358..678e8ebf6b 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -350,7 +350,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
got_mxoff = true;
}
- else if ((p = strstr(bufin, "First log segment after reset:")) != NULL)
+ else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL)
{
/* Skip the colon and any whitespace after it */
p = strchr(p, ':');
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 6528113628..4eebeadc8c 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -667,7 +667,7 @@ usage(void)
printf(_(" -F, --fork=FORK only show records that modify blocks in fork FORK;\n"
" valid names are main, fsm, vm, init\n"));
printf(_(" -n, --limit=N number of records to display\n"));
- printf(_(" -p, --path=PATH directory in which to find log segment files or a\n"
+ printf(_(" -p, --path=PATH directory in which to find WAL segment files or a\n"
" directory with a ./pg_wal that contains such files\n"
" (default: current directory, ./pg_wal, $PGDATA/pg_wal)\n"));
printf(_(" -q, --quiet do not print any output, except for errors\n"));
@@ -675,7 +675,7 @@ usage(void)
" use --rmgr=list to list valid resource manager names\n"));
printf(_(" -R, --relation=T/D/R only show records that modify blocks in relation T/D/R\n"));
printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n"));
- printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ printf(_(" -t, --timeline=TLI timeline from which to read WAL records\n"
" (default: 1 or the value used in STARTSEG)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" -w, --fullpage only show records with a full page write\n"));
--
2.25.1
[application/octet-stream] v6-0002-Consistently-use-WAL-file-s-in-docs.patch (18.6K, ../../CALj2ACV0ux_AeCV-xJkA6rbmsdN8KTHGOCx8vJCAa=DEtmgqaA@mail.gmail.com/3-v6-0002-Consistently-use-WAL-file-s-in-docs.patch)
download | inline diff:
From 2a89079004c0f85040bd3d504874bff1e9e34f39 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Wed, 20 Jul 2022 04:29:46 +0000
Subject: [PATCH v6] Consistently use "WAL file(s)" in docs
Authors: Kyotaro Horiguchi, Bharath Rupireddy
---
doc/src/sgml/backup.sgml | 14 ++++----
doc/src/sgml/config.sgml | 4 +--
doc/src/sgml/ref/pg_waldump.sgml | 10 +++---
doc/src/sgml/wal.sgml | 60 ++++++++++++++++----------------
4 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 73a774d3d7..cc5ae59ac2 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1095,7 +1095,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
require that you have enough free space on your system to hold two
copies of your existing database. If you do not have enough space,
you should at least save the contents of the cluster's <filename>pg_wal</filename>
- subdirectory, as it might contain logs which
+ subdirectory, as it might contain WAL files which
were not archived before the system went down.
</para>
</listitem>
@@ -1173,8 +1173,8 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
which tells <productname>PostgreSQL</productname> how to retrieve archived
WAL file segments. Like the <varname>archive_command</varname>, this is
a shell command string. It can contain <literal>%f</literal>, which is
- replaced by the name of the desired log file, and <literal>%p</literal>,
- which is replaced by the path name to copy the log file to.
+ replaced by the name of the desired WAL file, and <literal>%p</literal>,
+ which is replaced by the path name to copy the WAL file to.
(The path name is relative to the current working directory,
i.e., the cluster's data directory.)
Write <literal>%%</literal> if you need to embed an actual <literal>%</literal>
@@ -1462,9 +1462,9 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
commands are WAL-logged with the literal absolute path, and will
therefore be replayed as tablespace creations with the same
- absolute path. This might be undesirable if the log is being
+ absolute path. This might be undesirable if the WAL is being
replayed on a different machine. It can be dangerous even if the
- log is being replayed on the same machine, but into a new data
+ WAL is being replayed on the same machine, but into a new data
directory: the replay will still overwrite the contents of the
original tablespace. To avoid potential gotchas of this sort,
the best practice is to take a new base backup after creating or
@@ -1481,11 +1481,11 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
we might need to fix partially-written disk pages. Depending on
your system hardware and software, the risk of partial writes might
be small enough to ignore, in which case you can significantly
- reduce the total volume of archived logs by turning off page
+ reduce the total volume of archived WAL files by turning off page
snapshots using the <xref linkend="guc-full-page-writes"/>
parameter. (Read the notes and warnings in <xref linkend="wal"/>
before you do so.) Turning off page snapshots does not prevent
- use of the logs for PITR operations. An area for future
+ use of the WAL for PITR operations. An area for future
development is to compress archived WAL data by removing
unnecessary page copies even when <varname>full_page_writes</varname> is
on. In the meantime, administrators might wish to reduce the number
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 37fd80388c..8275e557ef 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4228,7 +4228,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Specifies the minimum size of past log file segments kept in the
+ Specifies the minimum size of past WAL files kept in the
<filename>pg_wal</filename>
directory, in case a standby server needs to fetch them for streaming
replication. If a standby
@@ -4821,7 +4821,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
needs to control the amount of time to wait for new WAL data to be
available. For example, in archive recovery, it is possible to
make the recovery more responsive in the detection of a new WAL
- log file by reducing the value of this parameter. On a system with
+ file by reducing the value of this parameter. On a system with
low WAL activity, increasing it reduces the amount of requests necessary
to access WAL archives, something useful for example in cloud
environments where the number of times an infrastructure is accessed
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 57746d9421..2e2166bb6f 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -53,7 +53,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">startseg</replaceable></term>
<listitem>
<para>
- Start reading at the specified log segment file. This implicitly determines
+ Start reading at the specified WAL segment file. This implicitly determines
the path in which files will be searched for, and the timeline to use.
</para>
</listitem>
@@ -63,7 +63,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">endseg</replaceable></term>
<listitem>
<para>
- Stop after reading the specified log segment file.
+ Stop after reading the specified WAL segment file.
</para>
</listitem>
</varlistentry>
@@ -141,7 +141,7 @@ PostgreSQL documentation
<term><option>--path=<replaceable>path</replaceable></option></term>
<listitem>
<para>
- Specifies a directory to search for log segment files or a
+ Specifies a directory to search for WAL segment files or a
directory with a <literal>pg_wal</literal> subdirectory that
contains such files. The default is to search in the current
directory, the <literal>pg_wal</literal> subdirectory of the
@@ -203,7 +203,7 @@ PostgreSQL documentation
<listitem>
<para>
WAL location at which to start reading. The default is to start reading
- the first valid log record found in the earliest file found.
+ the first valid WAL record found in the earliest file found.
</para>
</listitem>
</varlistentry>
@@ -213,7 +213,7 @@ PostgreSQL documentation
<term><option>--timeline=<replaceable>timeline</replaceable></option></term>
<listitem>
<para>
- Timeline from which to read log records. The default is to use the
+ Timeline from which to read WAL records. The default is to use the
value in <replaceable>startseg</replaceable>, if that is specified; otherwise, the
default is 1.
</para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 01f7379ebb..30842c0396 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -297,12 +297,12 @@
transaction processing. Briefly, <acronym>WAL</acronym>'s central
concept is that changes to data files (where tables and indexes
reside) must be written only after those changes have been logged,
- that is, after log records describing the changes have been flushed
+ that is, after WAL records describing the changes have been flushed
to permanent storage. If we follow this procedure, we do not need
to flush data pages to disk on every transaction commit, because we
know that in the event of a crash we will be able to recover the
database using the log: any changes that have not been applied to
- the data pages can be redone from the log records. (This is
+ the data pages can be redone from the WAL records. (This is
roll-forward recovery, also known as REDO.)
</para>
@@ -323,15 +323,15 @@
<para>
Using <acronym>WAL</acronym> results in a
- significantly reduced number of disk writes, because only the log
+ significantly reduced number of disk writes, because only the WAL
file needs to be flushed to disk to guarantee that a transaction is
committed, rather than every data file changed by the transaction.
- The log file is written sequentially,
- and so the cost of syncing the log is much less than the cost of
+ The WAL file is written sequentially,
+ and so the cost of syncing the WAL is much less than the cost of
flushing the data pages. This is especially true for servers
handling many small transactions touching different parts of the data
store. Furthermore, when the server is processing many small concurrent
- transactions, one <function>fsync</function> of the log file may
+ transactions, one <function>fsync</function> of the WAL file may
suffice to commit many transactions.
</para>
@@ -341,10 +341,10 @@
linkend="continuous-archiving"/>. By archiving the WAL data we can support
reverting to any time instant covered by the available WAL data:
we simply install a prior physical backup of the database, and
- replay the WAL log just as far as the desired time. What's more,
+ replay the WAL just as far as the desired time. What's more,
the physical backup doesn't have to be an instantaneous snapshot
of the database state — if it is made over some period of time,
- then replaying the WAL log for that period will fix any internal
+ then replaying the WAL for that period will fix any internal
inconsistencies.
</para>
</sect1>
@@ -497,15 +497,15 @@
that the heap and index data files have been updated with all
information written before that checkpoint. At checkpoint time, all
dirty data pages are flushed to disk and a special checkpoint record is
- written to the log file. (The change records were previously flushed
+ written to the WAL file. (The change records were previously flushed
to the <acronym>WAL</acronym> files.)
In the event of a crash, the crash recovery procedure looks at the latest
- checkpoint record to determine the point in the log (known as the redo
+ checkpoint record to determine the point in the WAL (known as the redo
record) from which it should start the REDO operation. Any changes made to
data files before that point are guaranteed to be already on disk.
- Hence, after a checkpoint, log segments preceding the one containing
+ Hence, after a checkpoint, WAL segments preceding the one containing
the redo record are no longer needed and can be recycled or removed. (When
- <acronym>WAL</acronym> archiving is being done, the log segments must be
+ <acronym>WAL</acronym> archiving is being done, the WAL segments must be
archived before being recycled or removed.)
</para>
@@ -544,7 +544,7 @@
another factor to consider. To ensure data page consistency,
the first modification of a data page after each checkpoint results in
logging the entire page content. In that case,
- a smaller checkpoint interval increases the volume of output to the WAL log,
+ a smaller checkpoint interval increases the volume of output to the WAL,
partially negating the goal of using a smaller interval,
and in any case causing more disk I/O.
</para>
@@ -614,10 +614,10 @@
<para>
The number of WAL segment files in <filename>pg_wal</filename> directory depends on
<varname>min_wal_size</varname>, <varname>max_wal_size</varname> and
- the amount of WAL generated in previous checkpoint cycles. When old log
+ the amount of WAL generated in previous checkpoint cycles. When old WAL
segment files are no longer needed, they are removed or recycled (that is,
renamed to become future segments in the numbered sequence). If, due to a
- short-term peak of log output rate, <varname>max_wal_size</varname> is
+ short-term peak of WAL output rate, <varname>max_wal_size</varname> is
exceeded, the unneeded segment files will be removed until the system
gets back under this limit. Below that limit, the system recycles enough
WAL files to cover the estimated need until the next checkpoint, and
@@ -650,7 +650,7 @@
which are similar to checkpoints in normal operation: the server forces
all its state to disk, updates the <filename>pg_control</filename> file to
indicate that the already-processed WAL data need not be scanned again,
- and then recycles any old log segment files in the <filename>pg_wal</filename>
+ and then recycles any old WAL segment files in the <filename>pg_wal</filename>
directory.
Restartpoints can't be performed more frequently than checkpoints on the
primary because restartpoints can only be performed at checkpoint records.
@@ -676,12 +676,12 @@
insertion) at a time when an exclusive lock is held on affected
data pages, so the operation needs to be as fast as possible. What
is worse, writing <acronym>WAL</acronym> buffers might also force the
- creation of a new log segment, which takes even more
+ creation of a new WAL segment, which takes even more
time. Normally, <acronym>WAL</acronym> buffers should be written
and flushed by an <function>XLogFlush</function> request, which is
made, for the most part, at transaction commit time to ensure that
transaction records are flushed to permanent storage. On systems
- with high log output, <function>XLogFlush</function> requests might
+ with high WAL output, <function>XLogFlush</function> requests might
not occur often enough to prevent <function>XLogInsertRecord</function>
from having to do writes. On such systems
one should increase the number of <acronym>WAL</acronym> buffers by
@@ -724,7 +724,7 @@
<varname>commit_delay</varname>, so this value is recommended as the
starting point to use when optimizing for a particular workload. While
tuning <varname>commit_delay</varname> is particularly useful when the
- WAL log is stored on high-latency rotating disks, benefits can be
+ WAL is stored on high-latency rotating disks, benefits can be
significant even on storage media with very fast sync times, such as
solid-state drives or RAID arrays with a battery-backed write cache;
but this should definitely be tested against a representative workload.
@@ -828,16 +828,16 @@
<para>
<acronym>WAL</acronym> is automatically enabled; no action is
required from the administrator except ensuring that the
- disk-space requirements for the <acronym>WAL</acronym> logs are met,
+ disk-space requirements for the <acronym>WAL</acronym> files are met,
and that any necessary tuning is done (see <xref
linkend="wal-configuration"/>).
</para>
<para>
<acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
- logs as each new record is written. The insert position is described by
+ files as each new record is written. The insert position is described by
a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
- the logs, increasing monotonically with each new record.
+ the WAL, increasing monotonically with each new record.
<acronym>LSN</acronym> values are returned as the datatype
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
compared to calculate the volume of <acronym>WAL</acronym> data that
@@ -846,12 +846,12 @@
</para>
<para>
- <acronym>WAL</acronym> logs are stored in the directory
+ <acronym>WAL</acronym> files are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
- <option>--with-wal-blocksize</option> configure option). The log record headers
+ <option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
@@ -861,7 +861,7 @@
</para>
<para>
- It is advantageous if the log is located on a different disk from the
+ It is advantageous if the WAL is located on a different disk from the
main database files. This can be achieved by moving the
<filename>pg_wal</filename> directory to another location (while the server
is shut down, of course) and creating a symbolic link from the
@@ -877,19 +877,19 @@
on the disk. A power failure in such a situation might lead to
irrecoverable data corruption. Administrators should try to ensure
that disks holding <productname>PostgreSQL</productname>'s
- <acronym>WAL</acronym> log files do not make such false reports.
+ <acronym>WAL</acronym> files do not make such false reports.
(See <xref linkend="wal-reliability"/>.)
</para>
<para>
- After a checkpoint has been made and the log flushed, the
+ After a checkpoint has been made and the WAL flushed, the
checkpoint's position is saved in the file
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
- scanning forward from the log location indicated in the checkpoint
+ scanning forward from the WAL location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
- log on the first page modification after a checkpoint (assuming
+ WAL on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"/> is not disabled), all pages
changed since the checkpoint will be restored to a consistent
state.
@@ -897,7 +897,7 @@
<para>
To deal with the case where <filename>pg_control</filename> is
- corrupt, we should support the possibility of scanning existing log
+ corrupt, we should support the possibility of scanning existing WAL
segments in reverse order — newest to oldest — in order to find the
latest checkpoint. This has not been implemented yet.
<filename>pg_control</filename> is small enough (less than one disk page)
--
2.25.1
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
@ 2022-07-20 07:25 ` Kyotaro Horiguchi <[email protected]>
2022-07-20 11:55 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Kyotaro Horiguchi @ 2022-07-20 07:25 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]
At Wed, 20 Jul 2022 10:02:22 +0530, Bharath Rupireddy <[email protected]> wrote in
> Done. PSA v6 patch set.
Thanks!
- Specifies the minimum size of past log file segments kept in the
+ Specifies the minimum size of past WAL files kept in the
- log file by reducing the value of this parameter. On a system with
+ file by reducing the value of this parameter. On a system with
Looks fine. And postgresq.conf.sample has the following lines:
#archive_library = '' # library to use to archive a logfile segment
#archive_command = '' # command to use to archive a logfile segment
#archive_timeout = 0 # force a logfile segment switch after this
#restore_command = '' # command to use to restore an archived logfile segment
Aren't they need the same fix?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-20 07:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
@ 2022-07-20 11:55 ` Bharath Rupireddy <[email protected]>
2022-07-21 04:20 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Bharath Rupireddy @ 2022-07-20 11:55 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: Nathan Bossart <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 20, 2022 at 12:55 PM Kyotaro Horiguchi
<[email protected]> wrote:
>
> At Wed, 20 Jul 2022 10:02:22 +0530, Bharath Rupireddy <[email protected]> wrote in
> > Done. PSA v6 patch set.
>
> Thanks!
>
> - Specifies the minimum size of past log file segments kept in the
> + Specifies the minimum size of past WAL files kept in the
>
> - log file by reducing the value of this parameter. On a system with
> + file by reducing the value of this parameter. On a system with
>
> Looks fine. And postgresq.conf.sample has the following lines:
>
> #archive_library = '' # library to use to archive a logfile segment
>
> #archive_command = '' # command to use to archive a logfile segment
>
> #archive_timeout = 0 # force a logfile segment switch after this
>
> #restore_command = '' # command to use to restore an archived logfile segment
>
> Aren't they need the same fix?
Indeed. Thanks. Now, they are in sync with their peers in .conf.sample
file as well as description in guc.c.
PSA v7 patch set.
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v7-0001-Use-WAL-segment-instead-of-log-segment.patch (9.0K, ../../CALj2ACW8YwHiCr5PqvW8625Wx1ZaaVumHY-uzS1JDabvbrgVCw@mail.gmail.com/2-v7-0001-Use-WAL-segment-instead-of-log-segment.patch)
download | inline diff:
From 6094c80f28c64904ede361672521be6b86993adb Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Wed, 20 Jul 2022 04:25:10 +0000
Subject: [PATCH v7] Use "WAL segment" instead of "log segment"
We are using "log segment" in various user-facing messages, the
term "log" can mean server logs as well. The "WAL segment" suits
well here and it is consistently used across the other user-facing
messages.
Author: Bharath Rupireddy
---
src/backend/access/transam/xlogreader.c | 10 +++++-----
src/backend/access/transam/xlogrecovery.c | 6 +++---
src/backend/access/transam/xlogutils.c | 4 ++--
src/backend/replication/walreceiver.c | 6 +++---
src/bin/pg_resetwal/pg_resetwal.c | 2 +-
src/bin/pg_upgrade/controldata.c | 2 +-
src/bin/pg_waldump/pg_waldump.c | 4 ++--
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index f3dc4b7797..58f1a32b00 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1209,7 +1209,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid magic number %04X in log segment %s, offset %u",
+ "invalid magic number %04X in WAL segment %s, offset %u",
hdr->xlp_magic,
fname,
offset);
@@ -1223,7 +1223,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1264,7 +1264,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
/* hmm, first page of file doesn't have a long header? */
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1283,7 +1283,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "unexpected pageaddr %X/%X in log segment %s, offset %u",
+ "unexpected pageaddr %X/%X in WAL segment %s, offset %u",
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
@@ -1308,7 +1308,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "out-of-sequence timeline ID %u (after %u) in log segment %s, offset %u",
+ "out-of-sequence timeline ID %u (after %u) in WAL segment %s, offset %u",
hdr->xlp_tli,
state->latestPageTLI,
fname,
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 5d6f1b5e46..306a9f40e9 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -3018,7 +3018,7 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
XLogFileName(fname, xlogreader->seg.ws_tli, segno,
wal_segment_size);
ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg("unexpected timeline ID %u in log segment %s, offset %u",
+ (errmsg("unexpected timeline ID %u in WAL segment %s, offset %u",
xlogreader->latestPageTLI,
fname,
offset)));
@@ -3223,13 +3223,13 @@ retry:
errno = save_errno;
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %u: %m",
+ errmsg("could not read from WAL segment %s, offset %u: %m",
fname, readOff)));
}
else
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %u: read %d of %zu",
+ errmsg("could not read from WAL segment %s, offset %u: read %d of %zu",
fname, readOff, r, (Size) XLOG_BLCKSZ)));
goto next_record_is_invalid;
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 0cda22597f..9e3a000768 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -1049,14 +1049,14 @@ WALReadRaiseError(WALReadError *errinfo)
errno = errinfo->wre_errno;
ereport(ERROR,
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %d: %m",
+ errmsg("could not read from WAL segment %s, offset %d: %m",
fname, errinfo->wre_off)));
}
else if (errinfo->wre_read == 0)
{
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %d: read %d of %d",
+ errmsg("could not read from WAL segment %s, offset %d: read %d of %d",
fname, errinfo->wre_off, errinfo->wre_read,
errinfo->wre_req)));
}
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 3d37c1fe62..3767466ef3 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -616,7 +616,7 @@ WalReceiverMain(void)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
@@ -930,7 +930,7 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr, TimeLineID tli)
errno = save_errno;
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not write to log segment %s "
+ errmsg("could not write to WAL segment %s "
"at offset %u, length %lu: %m",
xlogfname, startoff, (unsigned long) segbytes)));
}
@@ -1042,7 +1042,7 @@ XLogWalRcvClose(XLogRecPtr recptr, TimeLineID tli)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index d4772a2965..7adf79eeed 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -788,7 +788,7 @@ PrintNewControlValues(void)
XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID,
newXlogSegNo, WalSegSz);
- printf(_("First log segment after reset: %s\n"), fname);
+ printf(_("First WAL segment after reset: %s\n"), fname);
if (set_mxid != 0)
{
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index 07de918358..678e8ebf6b 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -350,7 +350,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
got_mxoff = true;
}
- else if ((p = strstr(bufin, "First log segment after reset:")) != NULL)
+ else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL)
{
/* Skip the colon and any whitespace after it */
p = strchr(p, ':');
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 6528113628..4eebeadc8c 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -667,7 +667,7 @@ usage(void)
printf(_(" -F, --fork=FORK only show records that modify blocks in fork FORK;\n"
" valid names are main, fsm, vm, init\n"));
printf(_(" -n, --limit=N number of records to display\n"));
- printf(_(" -p, --path=PATH directory in which to find log segment files or a\n"
+ printf(_(" -p, --path=PATH directory in which to find WAL segment files or a\n"
" directory with a ./pg_wal that contains such files\n"
" (default: current directory, ./pg_wal, $PGDATA/pg_wal)\n"));
printf(_(" -q, --quiet do not print any output, except for errors\n"));
@@ -675,7 +675,7 @@ usage(void)
" use --rmgr=list to list valid resource manager names\n"));
printf(_(" -R, --relation=T/D/R only show records that modify blocks in relation T/D/R\n"));
printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n"));
- printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ printf(_(" -t, --timeline=TLI timeline from which to read WAL records\n"
" (default: 1 or the value used in STARTSEG)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" -w, --fullpage only show records with a full page write\n"));
--
2.25.1
[application/octet-stream] v7-0002-Consistently-use-WAL-file-s-in-docs.patch (20.0K, ../../CALj2ACW8YwHiCr5PqvW8625Wx1ZaaVumHY-uzS1JDabvbrgVCw@mail.gmail.com/3-v7-0002-Consistently-use-WAL-file-s-in-docs.patch)
download | inline diff:
From 0e662610e1335a16529d9da6bb45cd9d410faa45 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Wed, 20 Jul 2022 11:53:03 +0000
Subject: [PATCH v7] Consistently use "WAL file(s)" in docs
Authors: Kyotaro Horiguchi, Bharath Rupireddy
---
doc/src/sgml/backup.sgml | 14 ++---
doc/src/sgml/config.sgml | 4 +-
doc/src/sgml/ref/pg_waldump.sgml | 10 ++--
doc/src/sgml/wal.sgml | 60 +++++++++----------
src/backend/utils/misc/postgresql.conf.sample | 8 +--
5 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 73a774d3d7..cc5ae59ac2 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1095,7 +1095,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
require that you have enough free space on your system to hold two
copies of your existing database. If you do not have enough space,
you should at least save the contents of the cluster's <filename>pg_wal</filename>
- subdirectory, as it might contain logs which
+ subdirectory, as it might contain WAL files which
were not archived before the system went down.
</para>
</listitem>
@@ -1173,8 +1173,8 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
which tells <productname>PostgreSQL</productname> how to retrieve archived
WAL file segments. Like the <varname>archive_command</varname>, this is
a shell command string. It can contain <literal>%f</literal>, which is
- replaced by the name of the desired log file, and <literal>%p</literal>,
- which is replaced by the path name to copy the log file to.
+ replaced by the name of the desired WAL file, and <literal>%p</literal>,
+ which is replaced by the path name to copy the WAL file to.
(The path name is relative to the current working directory,
i.e., the cluster's data directory.)
Write <literal>%%</literal> if you need to embed an actual <literal>%</literal>
@@ -1462,9 +1462,9 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
commands are WAL-logged with the literal absolute path, and will
therefore be replayed as tablespace creations with the same
- absolute path. This might be undesirable if the log is being
+ absolute path. This might be undesirable if the WAL is being
replayed on a different machine. It can be dangerous even if the
- log is being replayed on the same machine, but into a new data
+ WAL is being replayed on the same machine, but into a new data
directory: the replay will still overwrite the contents of the
original tablespace. To avoid potential gotchas of this sort,
the best practice is to take a new base backup after creating or
@@ -1481,11 +1481,11 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
we might need to fix partially-written disk pages. Depending on
your system hardware and software, the risk of partial writes might
be small enough to ignore, in which case you can significantly
- reduce the total volume of archived logs by turning off page
+ reduce the total volume of archived WAL files by turning off page
snapshots using the <xref linkend="guc-full-page-writes"/>
parameter. (Read the notes and warnings in <xref linkend="wal"/>
before you do so.) Turning off page snapshots does not prevent
- use of the logs for PITR operations. An area for future
+ use of the WAL for PITR operations. An area for future
development is to compress archived WAL data by removing
unnecessary page copies even when <varname>full_page_writes</varname> is
on. In the meantime, administrators might wish to reduce the number
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 37fd80388c..8275e557ef 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4228,7 +4228,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Specifies the minimum size of past log file segments kept in the
+ Specifies the minimum size of past WAL files kept in the
<filename>pg_wal</filename>
directory, in case a standby server needs to fetch them for streaming
replication. If a standby
@@ -4821,7 +4821,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
needs to control the amount of time to wait for new WAL data to be
available. For example, in archive recovery, it is possible to
make the recovery more responsive in the detection of a new WAL
- log file by reducing the value of this parameter. On a system with
+ file by reducing the value of this parameter. On a system with
low WAL activity, increasing it reduces the amount of requests necessary
to access WAL archives, something useful for example in cloud
environments where the number of times an infrastructure is accessed
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 57746d9421..2e2166bb6f 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -53,7 +53,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">startseg</replaceable></term>
<listitem>
<para>
- Start reading at the specified log segment file. This implicitly determines
+ Start reading at the specified WAL segment file. This implicitly determines
the path in which files will be searched for, and the timeline to use.
</para>
</listitem>
@@ -63,7 +63,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">endseg</replaceable></term>
<listitem>
<para>
- Stop after reading the specified log segment file.
+ Stop after reading the specified WAL segment file.
</para>
</listitem>
</varlistentry>
@@ -141,7 +141,7 @@ PostgreSQL documentation
<term><option>--path=<replaceable>path</replaceable></option></term>
<listitem>
<para>
- Specifies a directory to search for log segment files or a
+ Specifies a directory to search for WAL segment files or a
directory with a <literal>pg_wal</literal> subdirectory that
contains such files. The default is to search in the current
directory, the <literal>pg_wal</literal> subdirectory of the
@@ -203,7 +203,7 @@ PostgreSQL documentation
<listitem>
<para>
WAL location at which to start reading. The default is to start reading
- the first valid log record found in the earliest file found.
+ the first valid WAL record found in the earliest file found.
</para>
</listitem>
</varlistentry>
@@ -213,7 +213,7 @@ PostgreSQL documentation
<term><option>--timeline=<replaceable>timeline</replaceable></option></term>
<listitem>
<para>
- Timeline from which to read log records. The default is to use the
+ Timeline from which to read WAL records. The default is to use the
value in <replaceable>startseg</replaceable>, if that is specified; otherwise, the
default is 1.
</para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 01f7379ebb..30842c0396 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -297,12 +297,12 @@
transaction processing. Briefly, <acronym>WAL</acronym>'s central
concept is that changes to data files (where tables and indexes
reside) must be written only after those changes have been logged,
- that is, after log records describing the changes have been flushed
+ that is, after WAL records describing the changes have been flushed
to permanent storage. If we follow this procedure, we do not need
to flush data pages to disk on every transaction commit, because we
know that in the event of a crash we will be able to recover the
database using the log: any changes that have not been applied to
- the data pages can be redone from the log records. (This is
+ the data pages can be redone from the WAL records. (This is
roll-forward recovery, also known as REDO.)
</para>
@@ -323,15 +323,15 @@
<para>
Using <acronym>WAL</acronym> results in a
- significantly reduced number of disk writes, because only the log
+ significantly reduced number of disk writes, because only the WAL
file needs to be flushed to disk to guarantee that a transaction is
committed, rather than every data file changed by the transaction.
- The log file is written sequentially,
- and so the cost of syncing the log is much less than the cost of
+ The WAL file is written sequentially,
+ and so the cost of syncing the WAL is much less than the cost of
flushing the data pages. This is especially true for servers
handling many small transactions touching different parts of the data
store. Furthermore, when the server is processing many small concurrent
- transactions, one <function>fsync</function> of the log file may
+ transactions, one <function>fsync</function> of the WAL file may
suffice to commit many transactions.
</para>
@@ -341,10 +341,10 @@
linkend="continuous-archiving"/>. By archiving the WAL data we can support
reverting to any time instant covered by the available WAL data:
we simply install a prior physical backup of the database, and
- replay the WAL log just as far as the desired time. What's more,
+ replay the WAL just as far as the desired time. What's more,
the physical backup doesn't have to be an instantaneous snapshot
of the database state — if it is made over some period of time,
- then replaying the WAL log for that period will fix any internal
+ then replaying the WAL for that period will fix any internal
inconsistencies.
</para>
</sect1>
@@ -497,15 +497,15 @@
that the heap and index data files have been updated with all
information written before that checkpoint. At checkpoint time, all
dirty data pages are flushed to disk and a special checkpoint record is
- written to the log file. (The change records were previously flushed
+ written to the WAL file. (The change records were previously flushed
to the <acronym>WAL</acronym> files.)
In the event of a crash, the crash recovery procedure looks at the latest
- checkpoint record to determine the point in the log (known as the redo
+ checkpoint record to determine the point in the WAL (known as the redo
record) from which it should start the REDO operation. Any changes made to
data files before that point are guaranteed to be already on disk.
- Hence, after a checkpoint, log segments preceding the one containing
+ Hence, after a checkpoint, WAL segments preceding the one containing
the redo record are no longer needed and can be recycled or removed. (When
- <acronym>WAL</acronym> archiving is being done, the log segments must be
+ <acronym>WAL</acronym> archiving is being done, the WAL segments must be
archived before being recycled or removed.)
</para>
@@ -544,7 +544,7 @@
another factor to consider. To ensure data page consistency,
the first modification of a data page after each checkpoint results in
logging the entire page content. In that case,
- a smaller checkpoint interval increases the volume of output to the WAL log,
+ a smaller checkpoint interval increases the volume of output to the WAL,
partially negating the goal of using a smaller interval,
and in any case causing more disk I/O.
</para>
@@ -614,10 +614,10 @@
<para>
The number of WAL segment files in <filename>pg_wal</filename> directory depends on
<varname>min_wal_size</varname>, <varname>max_wal_size</varname> and
- the amount of WAL generated in previous checkpoint cycles. When old log
+ the amount of WAL generated in previous checkpoint cycles. When old WAL
segment files are no longer needed, they are removed or recycled (that is,
renamed to become future segments in the numbered sequence). If, due to a
- short-term peak of log output rate, <varname>max_wal_size</varname> is
+ short-term peak of WAL output rate, <varname>max_wal_size</varname> is
exceeded, the unneeded segment files will be removed until the system
gets back under this limit. Below that limit, the system recycles enough
WAL files to cover the estimated need until the next checkpoint, and
@@ -650,7 +650,7 @@
which are similar to checkpoints in normal operation: the server forces
all its state to disk, updates the <filename>pg_control</filename> file to
indicate that the already-processed WAL data need not be scanned again,
- and then recycles any old log segment files in the <filename>pg_wal</filename>
+ and then recycles any old WAL segment files in the <filename>pg_wal</filename>
directory.
Restartpoints can't be performed more frequently than checkpoints on the
primary because restartpoints can only be performed at checkpoint records.
@@ -676,12 +676,12 @@
insertion) at a time when an exclusive lock is held on affected
data pages, so the operation needs to be as fast as possible. What
is worse, writing <acronym>WAL</acronym> buffers might also force the
- creation of a new log segment, which takes even more
+ creation of a new WAL segment, which takes even more
time. Normally, <acronym>WAL</acronym> buffers should be written
and flushed by an <function>XLogFlush</function> request, which is
made, for the most part, at transaction commit time to ensure that
transaction records are flushed to permanent storage. On systems
- with high log output, <function>XLogFlush</function> requests might
+ with high WAL output, <function>XLogFlush</function> requests might
not occur often enough to prevent <function>XLogInsertRecord</function>
from having to do writes. On such systems
one should increase the number of <acronym>WAL</acronym> buffers by
@@ -724,7 +724,7 @@
<varname>commit_delay</varname>, so this value is recommended as the
starting point to use when optimizing for a particular workload. While
tuning <varname>commit_delay</varname> is particularly useful when the
- WAL log is stored on high-latency rotating disks, benefits can be
+ WAL is stored on high-latency rotating disks, benefits can be
significant even on storage media with very fast sync times, such as
solid-state drives or RAID arrays with a battery-backed write cache;
but this should definitely be tested against a representative workload.
@@ -828,16 +828,16 @@
<para>
<acronym>WAL</acronym> is automatically enabled; no action is
required from the administrator except ensuring that the
- disk-space requirements for the <acronym>WAL</acronym> logs are met,
+ disk-space requirements for the <acronym>WAL</acronym> files are met,
and that any necessary tuning is done (see <xref
linkend="wal-configuration"/>).
</para>
<para>
<acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
- logs as each new record is written. The insert position is described by
+ files as each new record is written. The insert position is described by
a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
- the logs, increasing monotonically with each new record.
+ the WAL, increasing monotonically with each new record.
<acronym>LSN</acronym> values are returned as the datatype
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
compared to calculate the volume of <acronym>WAL</acronym> data that
@@ -846,12 +846,12 @@
</para>
<para>
- <acronym>WAL</acronym> logs are stored in the directory
+ <acronym>WAL</acronym> files are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
- <option>--with-wal-blocksize</option> configure option). The log record headers
+ <option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
@@ -861,7 +861,7 @@
</para>
<para>
- It is advantageous if the log is located on a different disk from the
+ It is advantageous if the WAL is located on a different disk from the
main database files. This can be achieved by moving the
<filename>pg_wal</filename> directory to another location (while the server
is shut down, of course) and creating a symbolic link from the
@@ -877,19 +877,19 @@
on the disk. A power failure in such a situation might lead to
irrecoverable data corruption. Administrators should try to ensure
that disks holding <productname>PostgreSQL</productname>'s
- <acronym>WAL</acronym> log files do not make such false reports.
+ <acronym>WAL</acronym> files do not make such false reports.
(See <xref linkend="wal-reliability"/>.)
</para>
<para>
- After a checkpoint has been made and the log flushed, the
+ After a checkpoint has been made and the WAL flushed, the
checkpoint's position is saved in the file
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
- scanning forward from the log location indicated in the checkpoint
+ scanning forward from the WAL location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
- log on the first page modification after a checkpoint (assuming
+ WAL on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"/> is not disabled), all pages
changed since the checkpoint will be restored to a consistent
state.
@@ -897,7 +897,7 @@
<para>
To deal with the case where <filename>pg_control</filename> is
- corrupt, we should support the possibility of scanning existing log
+ corrupt, we should support the possibility of scanning existing WAL
segments in reverse order — newest to oldest — in order to find the
latest checkpoint. This has not been implemented yet.
<filename>pg_control</filename> is small enough (less than one disk page)
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index b4bc06e5f5..6bb37cbecf 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -251,21 +251,21 @@
#archive_mode = off # enables archiving; off, on, or always
# (change requires restart)
-#archive_library = '' # library to use to archive a logfile segment
+#archive_library = '' # library to use to archive a WAL file
# (empty string indicates archive_command should
# be used)
-#archive_command = '' # command to use to archive a logfile segment
+#archive_command = '' # command to use to archive a WAL file
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
-#archive_timeout = 0 # force a logfile segment switch after this
+#archive_timeout = 0 # force a WAL file switch after this
# number of seconds; 0 disables
# - Archive Recovery -
# These are only used in recovery mode.
-#restore_command = '' # command to use to restore an archived logfile segment
+#restore_command = '' # command to use to restore an archived WAL file
# placeholders: %p = path of file to restore
# %f = file name only
# e.g. 'cp /mnt/server/archivedir/%f %p'
--
2.25.1
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-20 07:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 11:55 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
@ 2022-07-21 04:20 ` Kyotaro Horiguchi <[email protected]>
2022-07-23 09:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Kyotaro Horiguchi @ 2022-07-21 04:20 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]
At Wed, 20 Jul 2022 17:25:33 +0530, Bharath Rupireddy <[email protected]> wrote in
> On Wed, Jul 20, 2022 at 12:55 PM Kyotaro Horiguchi
> <[email protected]> wrote:
> PSA v7 patch set.
Thanks. Looks perfect, but (sorry..) in the final checking, I found
"log archive" in the doc. If you agree to it please merge the
attached (or refined one) and I'd call it a day.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachments:
[text/x-patch] fix_log_WAL.patch (1.4K, ../../[email protected]/2-fix_log_WAL.patch)
download | inline diff:
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index c0b89a3c01..e5344eb277 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2659,7 +2659,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<listitem>
<para>
If set to true, the backup will wait until the last required WAL
- segment has been archived, or emit a warning if log archiving is
+ segment has been archived, or emit a warning if WAL archiving is
not enabled. If false, the backup will neither wait nor warn,
leaving the client responsible for ensuring the required log is
available. The default is true.
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index 56ac7b754b..e50f00afa8 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -318,7 +318,7 @@ PostgreSQL documentation
backup. This will include all write-ahead logs generated during
the backup. Unless the method <literal>none</literal> is specified,
it is possible to start a postmaster in the target
- directory without the need to consult the log archive, thus
+ directory without the need to consult the WAL archive, thus
making the output a completely standalone backup.
</para>
<para>
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-20 07:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 11:55 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-21 04:20 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
@ 2022-07-23 09:58 ` Bharath Rupireddy <[email protected]>
2022-09-14 22:41 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Tom Lane <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Bharath Rupireddy @ 2022-07-23 09:58 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: Nathan Bossart <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Jul 21, 2022 at 9:50 AM Kyotaro Horiguchi
<[email protected]> wrote:
>
> At Wed, 20 Jul 2022 17:25:33 +0530, Bharath Rupireddy <[email protected]> wrote in
> > On Wed, Jul 20, 2022 at 12:55 PM Kyotaro Horiguchi
> > <[email protected]> wrote:
> > PSA v7 patch set.
>
> Thanks. Looks perfect, but (sorry..) in the final checking, I found
> "log archive" in the doc. If you agree to it please merge the
> attached (or refined one) and I'd call it a day.
Merged. PSA v8 patch set.
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v8-0001-Use-WAL-segment-instead-of-log-segment.patch (9.0K, ../../CALj2ACVKmOP145_6wWCYAPU019tTEio8Gwxe7aicyJGy516zug@mail.gmail.com/2-v8-0001-Use-WAL-segment-instead-of-log-segment.patch)
download | inline diff:
From ec8879007aac9a5b81abf6c627acc7d65c178944 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Sat, 23 Jul 2022 09:36:56 +0000
Subject: [PATCH v8] Use "WAL segment" instead of "log segment"
We are using "log segment" in various user-facing messages, the
term "log" can mean server logs as well. The "WAL segment" suits
well here and it is consistently used across the other user-facing
messages.
Author: Bharath Rupireddy
---
src/backend/access/transam/xlogreader.c | 10 +++++-----
src/backend/access/transam/xlogrecovery.c | 6 +++---
src/backend/access/transam/xlogutils.c | 4 ++--
src/backend/replication/walreceiver.c | 6 +++---
src/bin/pg_resetwal/pg_resetwal.c | 2 +-
src/bin/pg_upgrade/controldata.c | 2 +-
src/bin/pg_waldump/pg_waldump.c | 4 ++--
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index f3dc4b7797..58f1a32b00 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -1209,7 +1209,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid magic number %04X in log segment %s, offset %u",
+ "invalid magic number %04X in WAL segment %s, offset %u",
hdr->xlp_magic,
fname,
offset);
@@ -1223,7 +1223,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1264,7 +1264,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
/* hmm, first page of file doesn't have a long header? */
report_invalid_record(state,
- "invalid info bits %04X in log segment %s, offset %u",
+ "invalid info bits %04X in WAL segment %s, offset %u",
hdr->xlp_info,
fname,
offset);
@@ -1283,7 +1283,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "unexpected pageaddr %X/%X in log segment %s, offset %u",
+ "unexpected pageaddr %X/%X in WAL segment %s, offset %u",
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
@@ -1308,7 +1308,7 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogFileName(fname, state->seg.ws_tli, segno, state->segcxt.ws_segsize);
report_invalid_record(state,
- "out-of-sequence timeline ID %u (after %u) in log segment %s, offset %u",
+ "out-of-sequence timeline ID %u (after %u) in WAL segment %s, offset %u",
hdr->xlp_tli,
state->latestPageTLI,
fname,
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 5d6f1b5e46..306a9f40e9 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -3018,7 +3018,7 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
XLogFileName(fname, xlogreader->seg.ws_tli, segno,
wal_segment_size);
ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg("unexpected timeline ID %u in log segment %s, offset %u",
+ (errmsg("unexpected timeline ID %u in WAL segment %s, offset %u",
xlogreader->latestPageTLI,
fname,
offset)));
@@ -3223,13 +3223,13 @@ retry:
errno = save_errno;
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %u: %m",
+ errmsg("could not read from WAL segment %s, offset %u: %m",
fname, readOff)));
}
else
ereport(emode_for_corrupt_record(emode, targetPagePtr + reqLen),
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %u: read %d of %zu",
+ errmsg("could not read from WAL segment %s, offset %u: read %d of %zu",
fname, readOff, r, (Size) XLOG_BLCKSZ)));
goto next_record_is_invalid;
}
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 0cda22597f..9e3a000768 100644
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -1049,14 +1049,14 @@ WALReadRaiseError(WALReadError *errinfo)
errno = errinfo->wre_errno;
ereport(ERROR,
(errcode_for_file_access(),
- errmsg("could not read from log segment %s, offset %d: %m",
+ errmsg("could not read from WAL segment %s, offset %d: %m",
fname, errinfo->wre_off)));
}
else if (errinfo->wre_read == 0)
{
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("could not read from log segment %s, offset %d: read %d of %d",
+ errmsg("could not read from WAL segment %s, offset %d: read %d of %d",
fname, errinfo->wre_off, errinfo->wre_read,
errinfo->wre_req)));
}
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 3d37c1fe62..3767466ef3 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -616,7 +616,7 @@ WalReceiverMain(void)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
@@ -930,7 +930,7 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr, TimeLineID tli)
errno = save_errno;
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not write to log segment %s "
+ errmsg("could not write to WAL segment %s "
"at offset %u, length %lu: %m",
xlogfname, startoff, (unsigned long) segbytes)));
}
@@ -1042,7 +1042,7 @@ XLogWalRcvClose(XLogRecPtr recptr, TimeLineID tli)
if (close(recvFile) != 0)
ereport(PANIC,
(errcode_for_file_access(),
- errmsg("could not close log segment %s: %m",
+ errmsg("could not close WAL segment %s: %m",
xlogfname)));
/*
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index d4772a2965..7adf79eeed 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -788,7 +788,7 @@ PrintNewControlValues(void)
XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID,
newXlogSegNo, WalSegSz);
- printf(_("First log segment after reset: %s\n"), fname);
+ printf(_("First WAL segment after reset: %s\n"), fname);
if (set_mxid != 0)
{
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index 07de918358..678e8ebf6b 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -350,7 +350,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
got_mxoff = true;
}
- else if ((p = strstr(bufin, "First log segment after reset:")) != NULL)
+ else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL)
{
/* Skip the colon and any whitespace after it */
p = strchr(p, ':');
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 6528113628..4eebeadc8c 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -667,7 +667,7 @@ usage(void)
printf(_(" -F, --fork=FORK only show records that modify blocks in fork FORK;\n"
" valid names are main, fsm, vm, init\n"));
printf(_(" -n, --limit=N number of records to display\n"));
- printf(_(" -p, --path=PATH directory in which to find log segment files or a\n"
+ printf(_(" -p, --path=PATH directory in which to find WAL segment files or a\n"
" directory with a ./pg_wal that contains such files\n"
" (default: current directory, ./pg_wal, $PGDATA/pg_wal)\n"));
printf(_(" -q, --quiet do not print any output, except for errors\n"));
@@ -675,7 +675,7 @@ usage(void)
" use --rmgr=list to list valid resource manager names\n"));
printf(_(" -R, --relation=T/D/R only show records that modify blocks in relation T/D/R\n"));
printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n"));
- printf(_(" -t, --timeline=TLI timeline from which to read log records\n"
+ printf(_(" -t, --timeline=TLI timeline from which to read WAL records\n"
" (default: 1 or the value used in STARTSEG)\n"));
printf(_(" -V, --version output version information, then exit\n"));
printf(_(" -w, --fullpage only show records with a full page write\n"));
--
2.34.1
[application/octet-stream] v8-0002-Consistently-use-WAL-file-s-in-docs.patch (21.5K, ../../CALj2ACVKmOP145_6wWCYAPU019tTEio8Gwxe7aicyJGy516zug@mail.gmail.com/3-v8-0002-Consistently-use-WAL-file-s-in-docs.patch)
download | inline diff:
From e52b42062e04d026d7efcd9d8bebf03fcf77e8b2 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Sat, 23 Jul 2022 09:55:57 +0000
Subject: [PATCH v8] Consistently use "WAL file(s)" in docs
Authors: Kyotaro Horiguchi, Bharath Rupireddy
---
doc/src/sgml/backup.sgml | 14 ++---
doc/src/sgml/config.sgml | 4 +-
doc/src/sgml/protocol.sgml | 2 +-
doc/src/sgml/ref/pg_basebackup.sgml | 2 +-
doc/src/sgml/ref/pg_waldump.sgml | 10 ++--
doc/src/sgml/wal.sgml | 60 +++++++++----------
src/backend/utils/misc/postgresql.conf.sample | 8 +--
7 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 73a774d3d7..cc5ae59ac2 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1095,7 +1095,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
require that you have enough free space on your system to hold two
copies of your existing database. If you do not have enough space,
you should at least save the contents of the cluster's <filename>pg_wal</filename>
- subdirectory, as it might contain logs which
+ subdirectory, as it might contain WAL files which
were not archived before the system went down.
</para>
</listitem>
@@ -1173,8 +1173,8 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
which tells <productname>PostgreSQL</productname> how to retrieve archived
WAL file segments. Like the <varname>archive_command</varname>, this is
a shell command string. It can contain <literal>%f</literal>, which is
- replaced by the name of the desired log file, and <literal>%p</literal>,
- which is replaced by the path name to copy the log file to.
+ replaced by the name of the desired WAL file, and <literal>%p</literal>,
+ which is replaced by the path name to copy the WAL file to.
(The path name is relative to the current working directory,
i.e., the cluster's data directory.)
Write <literal>%%</literal> if you need to embed an actual <literal>%</literal>
@@ -1462,9 +1462,9 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
<link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
commands are WAL-logged with the literal absolute path, and will
therefore be replayed as tablespace creations with the same
- absolute path. This might be undesirable if the log is being
+ absolute path. This might be undesirable if the WAL is being
replayed on a different machine. It can be dangerous even if the
- log is being replayed on the same machine, but into a new data
+ WAL is being replayed on the same machine, but into a new data
directory: the replay will still overwrite the contents of the
original tablespace. To avoid potential gotchas of this sort,
the best practice is to take a new base backup after creating or
@@ -1481,11 +1481,11 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
we might need to fix partially-written disk pages. Depending on
your system hardware and software, the risk of partial writes might
be small enough to ignore, in which case you can significantly
- reduce the total volume of archived logs by turning off page
+ reduce the total volume of archived WAL files by turning off page
snapshots using the <xref linkend="guc-full-page-writes"/>
parameter. (Read the notes and warnings in <xref linkend="wal"/>
before you do so.) Turning off page snapshots does not prevent
- use of the logs for PITR operations. An area for future
+ use of the WAL for PITR operations. An area for future
development is to compress archived WAL data by removing
unnecessary page copies even when <varname>full_page_writes</varname> is
on. In the meantime, administrators might wish to reduce the number
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e2d728e0c4..4e92c0c5eb 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4228,7 +4228,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</term>
<listitem>
<para>
- Specifies the minimum size of past log file segments kept in the
+ Specifies the minimum size of past WAL files kept in the
<filename>pg_wal</filename>
directory, in case a standby server needs to fetch them for streaming
replication. If a standby
@@ -4821,7 +4821,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
needs to control the amount of time to wait for new WAL data to be
available. For example, in archive recovery, it is possible to
make the recovery more responsive in the detection of a new WAL
- log file by reducing the value of this parameter. On a system with
+ file by reducing the value of this parameter. On a system with
low WAL activity, increasing it reduces the amount of requests necessary
to access WAL archives, something useful for example in cloud
environments where the number of times an infrastructure is accessed
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index c0b89a3c01..e5344eb277 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2659,7 +2659,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<listitem>
<para>
If set to true, the backup will wait until the last required WAL
- segment has been archived, or emit a warning if log archiving is
+ segment has been archived, or emit a warning if WAL archiving is
not enabled. If false, the backup will neither wait nor warn,
leaving the client responsible for ensuring the required log is
available. The default is true.
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index 56ac7b754b..e50f00afa8 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -318,7 +318,7 @@ PostgreSQL documentation
backup. This will include all write-ahead logs generated during
the backup. Unless the method <literal>none</literal> is specified,
it is possible to start a postmaster in the target
- directory without the need to consult the log archive, thus
+ directory without the need to consult the WAL archive, thus
making the output a completely standalone backup.
</para>
<para>
diff --git a/doc/src/sgml/ref/pg_waldump.sgml b/doc/src/sgml/ref/pg_waldump.sgml
index 57746d9421..2e2166bb6f 100644
--- a/doc/src/sgml/ref/pg_waldump.sgml
+++ b/doc/src/sgml/ref/pg_waldump.sgml
@@ -53,7 +53,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">startseg</replaceable></term>
<listitem>
<para>
- Start reading at the specified log segment file. This implicitly determines
+ Start reading at the specified WAL segment file. This implicitly determines
the path in which files will be searched for, and the timeline to use.
</para>
</listitem>
@@ -63,7 +63,7 @@ PostgreSQL documentation
<term><replaceable class="parameter">endseg</replaceable></term>
<listitem>
<para>
- Stop after reading the specified log segment file.
+ Stop after reading the specified WAL segment file.
</para>
</listitem>
</varlistentry>
@@ -141,7 +141,7 @@ PostgreSQL documentation
<term><option>--path=<replaceable>path</replaceable></option></term>
<listitem>
<para>
- Specifies a directory to search for log segment files or a
+ Specifies a directory to search for WAL segment files or a
directory with a <literal>pg_wal</literal> subdirectory that
contains such files. The default is to search in the current
directory, the <literal>pg_wal</literal> subdirectory of the
@@ -203,7 +203,7 @@ PostgreSQL documentation
<listitem>
<para>
WAL location at which to start reading. The default is to start reading
- the first valid log record found in the earliest file found.
+ the first valid WAL record found in the earliest file found.
</para>
</listitem>
</varlistentry>
@@ -213,7 +213,7 @@ PostgreSQL documentation
<term><option>--timeline=<replaceable>timeline</replaceable></option></term>
<listitem>
<para>
- Timeline from which to read log records. The default is to use the
+ Timeline from which to read WAL records. The default is to use the
value in <replaceable>startseg</replaceable>, if that is specified; otherwise, the
default is 1.
</para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 01f7379ebb..30842c0396 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -297,12 +297,12 @@
transaction processing. Briefly, <acronym>WAL</acronym>'s central
concept is that changes to data files (where tables and indexes
reside) must be written only after those changes have been logged,
- that is, after log records describing the changes have been flushed
+ that is, after WAL records describing the changes have been flushed
to permanent storage. If we follow this procedure, we do not need
to flush data pages to disk on every transaction commit, because we
know that in the event of a crash we will be able to recover the
database using the log: any changes that have not been applied to
- the data pages can be redone from the log records. (This is
+ the data pages can be redone from the WAL records. (This is
roll-forward recovery, also known as REDO.)
</para>
@@ -323,15 +323,15 @@
<para>
Using <acronym>WAL</acronym> results in a
- significantly reduced number of disk writes, because only the log
+ significantly reduced number of disk writes, because only the WAL
file needs to be flushed to disk to guarantee that a transaction is
committed, rather than every data file changed by the transaction.
- The log file is written sequentially,
- and so the cost of syncing the log is much less than the cost of
+ The WAL file is written sequentially,
+ and so the cost of syncing the WAL is much less than the cost of
flushing the data pages. This is especially true for servers
handling many small transactions touching different parts of the data
store. Furthermore, when the server is processing many small concurrent
- transactions, one <function>fsync</function> of the log file may
+ transactions, one <function>fsync</function> of the WAL file may
suffice to commit many transactions.
</para>
@@ -341,10 +341,10 @@
linkend="continuous-archiving"/>. By archiving the WAL data we can support
reverting to any time instant covered by the available WAL data:
we simply install a prior physical backup of the database, and
- replay the WAL log just as far as the desired time. What's more,
+ replay the WAL just as far as the desired time. What's more,
the physical backup doesn't have to be an instantaneous snapshot
of the database state — if it is made over some period of time,
- then replaying the WAL log for that period will fix any internal
+ then replaying the WAL for that period will fix any internal
inconsistencies.
</para>
</sect1>
@@ -497,15 +497,15 @@
that the heap and index data files have been updated with all
information written before that checkpoint. At checkpoint time, all
dirty data pages are flushed to disk and a special checkpoint record is
- written to the log file. (The change records were previously flushed
+ written to the WAL file. (The change records were previously flushed
to the <acronym>WAL</acronym> files.)
In the event of a crash, the crash recovery procedure looks at the latest
- checkpoint record to determine the point in the log (known as the redo
+ checkpoint record to determine the point in the WAL (known as the redo
record) from which it should start the REDO operation. Any changes made to
data files before that point are guaranteed to be already on disk.
- Hence, after a checkpoint, log segments preceding the one containing
+ Hence, after a checkpoint, WAL segments preceding the one containing
the redo record are no longer needed and can be recycled or removed. (When
- <acronym>WAL</acronym> archiving is being done, the log segments must be
+ <acronym>WAL</acronym> archiving is being done, the WAL segments must be
archived before being recycled or removed.)
</para>
@@ -544,7 +544,7 @@
another factor to consider. To ensure data page consistency,
the first modification of a data page after each checkpoint results in
logging the entire page content. In that case,
- a smaller checkpoint interval increases the volume of output to the WAL log,
+ a smaller checkpoint interval increases the volume of output to the WAL,
partially negating the goal of using a smaller interval,
and in any case causing more disk I/O.
</para>
@@ -614,10 +614,10 @@
<para>
The number of WAL segment files in <filename>pg_wal</filename> directory depends on
<varname>min_wal_size</varname>, <varname>max_wal_size</varname> and
- the amount of WAL generated in previous checkpoint cycles. When old log
+ the amount of WAL generated in previous checkpoint cycles. When old WAL
segment files are no longer needed, they are removed or recycled (that is,
renamed to become future segments in the numbered sequence). If, due to a
- short-term peak of log output rate, <varname>max_wal_size</varname> is
+ short-term peak of WAL output rate, <varname>max_wal_size</varname> is
exceeded, the unneeded segment files will be removed until the system
gets back under this limit. Below that limit, the system recycles enough
WAL files to cover the estimated need until the next checkpoint, and
@@ -650,7 +650,7 @@
which are similar to checkpoints in normal operation: the server forces
all its state to disk, updates the <filename>pg_control</filename> file to
indicate that the already-processed WAL data need not be scanned again,
- and then recycles any old log segment files in the <filename>pg_wal</filename>
+ and then recycles any old WAL segment files in the <filename>pg_wal</filename>
directory.
Restartpoints can't be performed more frequently than checkpoints on the
primary because restartpoints can only be performed at checkpoint records.
@@ -676,12 +676,12 @@
insertion) at a time when an exclusive lock is held on affected
data pages, so the operation needs to be as fast as possible. What
is worse, writing <acronym>WAL</acronym> buffers might also force the
- creation of a new log segment, which takes even more
+ creation of a new WAL segment, which takes even more
time. Normally, <acronym>WAL</acronym> buffers should be written
and flushed by an <function>XLogFlush</function> request, which is
made, for the most part, at transaction commit time to ensure that
transaction records are flushed to permanent storage. On systems
- with high log output, <function>XLogFlush</function> requests might
+ with high WAL output, <function>XLogFlush</function> requests might
not occur often enough to prevent <function>XLogInsertRecord</function>
from having to do writes. On such systems
one should increase the number of <acronym>WAL</acronym> buffers by
@@ -724,7 +724,7 @@
<varname>commit_delay</varname>, so this value is recommended as the
starting point to use when optimizing for a particular workload. While
tuning <varname>commit_delay</varname> is particularly useful when the
- WAL log is stored on high-latency rotating disks, benefits can be
+ WAL is stored on high-latency rotating disks, benefits can be
significant even on storage media with very fast sync times, such as
solid-state drives or RAID arrays with a battery-backed write cache;
but this should definitely be tested against a representative workload.
@@ -828,16 +828,16 @@
<para>
<acronym>WAL</acronym> is automatically enabled; no action is
required from the administrator except ensuring that the
- disk-space requirements for the <acronym>WAL</acronym> logs are met,
+ disk-space requirements for the <acronym>WAL</acronym> files are met,
and that any necessary tuning is done (see <xref
linkend="wal-configuration"/>).
</para>
<para>
<acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
- logs as each new record is written. The insert position is described by
+ files as each new record is written. The insert position is described by
a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
- the logs, increasing monotonically with each new record.
+ the WAL, increasing monotonically with each new record.
<acronym>LSN</acronym> values are returned as the datatype
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
compared to calculate the volume of <acronym>WAL</acronym> data that
@@ -846,12 +846,12 @@
</para>
<para>
- <acronym>WAL</acronym> logs are stored in the directory
+ <acronym>WAL</acronym> files are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
- <option>--with-wal-blocksize</option> configure option). The log record headers
+ <option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
@@ -861,7 +861,7 @@
</para>
<para>
- It is advantageous if the log is located on a different disk from the
+ It is advantageous if the WAL is located on a different disk from the
main database files. This can be achieved by moving the
<filename>pg_wal</filename> directory to another location (while the server
is shut down, of course) and creating a symbolic link from the
@@ -877,19 +877,19 @@
on the disk. A power failure in such a situation might lead to
irrecoverable data corruption. Administrators should try to ensure
that disks holding <productname>PostgreSQL</productname>'s
- <acronym>WAL</acronym> log files do not make such false reports.
+ <acronym>WAL</acronym> files do not make such false reports.
(See <xref linkend="wal-reliability"/>.)
</para>
<para>
- After a checkpoint has been made and the log flushed, the
+ After a checkpoint has been made and the WAL flushed, the
checkpoint's position is saved in the file
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
- scanning forward from the log location indicated in the checkpoint
+ scanning forward from the WAL location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
- log on the first page modification after a checkpoint (assuming
+ WAL on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"/> is not disabled), all pages
changed since the checkpoint will be restored to a consistent
state.
@@ -897,7 +897,7 @@
<para>
To deal with the case where <filename>pg_control</filename> is
- corrupt, we should support the possibility of scanning existing log
+ corrupt, we should support the possibility of scanning existing WAL
segments in reverse order — newest to oldest — in order to find the
latest checkpoint. This has not been implemented yet.
<filename>pg_control</filename> is small enough (less than one disk page)
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index b4bc06e5f5..6bb37cbecf 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -251,21 +251,21 @@
#archive_mode = off # enables archiving; off, on, or always
# (change requires restart)
-#archive_library = '' # library to use to archive a logfile segment
+#archive_library = '' # library to use to archive a WAL file
# (empty string indicates archive_command should
# be used)
-#archive_command = '' # command to use to archive a logfile segment
+#archive_command = '' # command to use to archive a WAL file
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
-#archive_timeout = 0 # force a logfile segment switch after this
+#archive_timeout = 0 # force a WAL file switch after this
# number of seconds; 0 disables
# - Archive Recovery -
# These are only used in recovery mode.
-#restore_command = '' # command to use to restore an archived logfile segment
+#restore_command = '' # command to use to restore an archived WAL file
# placeholders: %p = path of file to restore
# %f = file name only
# e.g. 'cp /mnt/server/archivedir/%f %p'
--
2.34.1
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-20 07:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 11:55 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-21 04:20 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-23 09:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
@ 2022-09-14 22:41 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Tom Lane @ 2022-09-14 22:41 UTC (permalink / raw)
To: Bharath Rupireddy <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; Nathan Bossart <[email protected]>; PostgreSQL Hackers <[email protected]>
Bharath Rupireddy <[email protected]> writes:
> Merged. PSA v8 patch set.
Pushed, thanks.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
@ 2023-01-07 22:59 Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Karl O. Pinc @ 2023-01-07 22:59 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Tom Lane <[email protected]>; Devrim Gündüz <[email protected]>; Joe Conway <[email protected]>; pgsql-hackers
Hello,
This is a review of Peter's 2 patches. I see only 1 small problem.
+++
Looking at the documentation, a "postmaster" in the glossary is
defined as the controlling process. This works; it needs to be called
something. There is still a postmaster.pid (etc.) in the data
directory.
The word "postmaster" (case insensitive) shows up 84 times in the
documentation. I looked at all of these.
I see a possible problem at line 1,412 of runtime.sgml, the "Linux
Memory Overcommit" section. It talks about the postmaster's startup
script invoking the postmaster. It might, possibly, be better to say
that "postgres" is invoked, that being the name of the invoked program.
There's a similar usage at line 1,416. On the other hand, the existing
text makes it quite clear what is going on and there's a lot to be said
for consistently using the word "postmaster". I mention this only in
case somebody deems it significant. Perhaps there's a way to use
markup, identifying "postgres" as a program with a name in the file
system, to make things more clear. Most likely, nobody will care.
In doc/src/sgml/ref/allfiles.sgml at line 222 there is an ENTITY
defined which references the deleted postmaster.sgml file. Since I
did a maintainer-clean, and the patch deletes the postmaster.sgml
file, and I don't see any references to the entity in the docs, I
believe that this line should be removed. (In other words, I don't
think this file is automatically maintained.)
After applying the patches the documentation seems to build just fine.
I have not run contrib/start-scripts/{freebsd,linux}, but the patch
looks fine and the result of applying the patch looks fine, and the
patch is a one-line simple replacement of "postmaster" with "postgres"
so I expect no problems.
The modification to src/port/path.c is in a comment, so it will surely
not affect anything at runtime. And the changed comment looks right
to me.
There's thousands of lines of comments in the code where "postmaster"
(case insensitive) shows up after applying the patches. I've not
reviewed any of these. Or looked for odd variable names, or
references in the code to the postmaster binary - by name, etc. I'm
not sure where it would make sense to look for such problems.
Aside from the "allfiles.sgml" problem, I see no reason why these 2
patches should not be applied. As mentioned by others, I don't have
strong feelings about getting rid of the postmaster symlink. But I
did pick this patch to review because I remember, once upon a time,
being slightly confused by a "postmaster" in the process list.
Regards,
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
@ 2023-01-07 23:38 ` Tom Lane <[email protected]>
2023-01-08 00:33 ` Re: drop postmaster symlink Joe Conway <[email protected]>
2023-01-08 01:56 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
0 siblings, 2 replies; 23+ messages in thread
From: Tom Lane @ 2023-01-07 23:38 UTC (permalink / raw)
To: Karl O. Pinc <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Devrim Gündüz <[email protected]>; Joe Conway <[email protected]>; pgsql-hackers
"Karl O. Pinc" <[email protected]> writes:
> This is a review of Peter's 2 patches. I see only 1 small problem.
> Looking at the documentation, a "postmaster" in the glossary is
> defined as the controlling process. This works; it needs to be called
> something. There is still a postmaster.pid (etc.) in the data
> directory.
> The word "postmaster" (case insensitive) shows up 84 times in the
> documentation. I looked at all of these.
Hmm ... I thought this patch was about getting rid of the
admittedly-obsolete installed symlink. If it's trying to get rid of
the "postmaster" terminology for our parent process, I'm very strongly
against that, either as regards to code or documentation.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
@ 2023-01-08 00:33 ` Joe Conway <[email protected]>
2023-01-08 01:57 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
1 sibling, 1 reply; 23+ messages in thread
From: Joe Conway @ 2023-01-08 00:33 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Karl O. Pinc <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Devrim Gündüz <[email protected]>; pgsql-hackers
On 1/7/23 18:38, Tom Lane wrote:
> "Karl O. Pinc" <[email protected]> writes:
>> This is a review of Peter's 2 patches. I see only 1 small problem.
>
>> Looking at the documentation, a "postmaster" in the glossary is
>> defined as the controlling process. This works; it needs to be called
>> something. There is still a postmaster.pid (etc.) in the data
>> directory.
>
>> The word "postmaster" (case insensitive) shows up 84 times in the
>> documentation. I looked at all of these.
>
> Hmm ... I thought this patch was about getting rid of the
> admittedly-obsolete installed symlink.
That was my understanding too.
> If it's trying to get rid of the "postmaster" terminology for our
> parent process, I'm very strongly against that, either as regards to
> code or documentation.
+1
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
2023-01-08 00:33 ` Re: drop postmaster symlink Joe Conway <[email protected]>
@ 2023-01-08 01:57 ` Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Karl O. Pinc @ 2023-01-08 01:57 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Devrim Gündüz <[email protected]>; pgsql-hackers
On Sat, 7 Jan 2023 19:33:38 -0500
Joe Conway <[email protected]> wrote:
> On 1/7/23 18:38, Tom Lane wrote:
> > "Karl O. Pinc" <[email protected]> writes:
> >> This is a review of Peter's 2 patches. I see only 1 small
> >> problem.
The small problem is a reference to a deleted file.
Regards,
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
@ 2023-01-08 01:56 ` Karl O. Pinc <[email protected]>
2023-01-08 04:29 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
1 sibling, 1 reply; 23+ messages in thread
From: Karl O. Pinc @ 2023-01-08 01:56 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Devrim Gündüz <[email protected]>; Joe Conway <[email protected]>; pgsql-hackers
On Sat, 07 Jan 2023 18:38:25 -0500
Tom Lane <[email protected]> wrote:
> "Karl O. Pinc" <[email protected]> writes:
> > This is a review of Peter's 2 patches. I see only 1 small problem.
> >
>
> > Looking at the documentation, a "postmaster" in the glossary is
> > defined as the controlling process. This works; it needs to be
> > called something. There is still a postmaster.pid (etc.) in the
> > data directory.
>
> > The word "postmaster" (case insensitive) shows up 84 times in the
> > documentation. I looked at all of these.
>
> Hmm ... I thought this patch was about getting rid of the
> admittedly-obsolete installed symlink. If it's trying to get rid of
> the "postmaster" terminology for our parent process, I'm very strongly
> against that, either as regards to code or documentation.
No. It's about getting rid of the symlink. I was grepping around
to look for use of the symlink, started with the glossary just
to be sure, and saw that "postmaster" is consistently (I think)
used to refer to the controlling, parent, process. And wrote
down what I was doing and what I found as I went along. And then
sent out my notes.
Sorry for the confusion.
Regards,
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
2023-01-08 01:56 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
@ 2023-01-08 04:29 ` Karl O. Pinc <[email protected]>
2023-01-08 20:17 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
0 siblings, 1 reply; 23+ messages in thread
From: Karl O. Pinc @ 2023-01-08 04:29 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Devrim Gündüz <[email protected]>; Joe Conway <[email protected]>; pgsql-hackers
On Sat, 7 Jan 2023 19:56:08 -0600
"Karl O. Pinc" <[email protected]> wrote:
> On Sat, 07 Jan 2023 18:38:25 -0500
> Tom Lane <[email protected]> wrote:
>
> > "Karl O. Pinc" <[email protected]> writes:
> > > This is a review of Peter's 2 patches. I see only 1 small
> > > problem. ...
> > Hmm ... I thought this patch was about getting rid of the
> > admittedly-obsolete installed symlink. ...
> No. It's about getting rid of the symlink.
The only way I could think of to review a patch
that removes something is to report all the places
I looked where a reference to the symlink might be.
Then report what I found each place I looked and
report if there's a problem, or might be.
That way the committer knows where I didn't look if there's
more that needs removing.
Apologies that this was not clear.
Regards,
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: drop postmaster symlink
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
2023-01-08 01:56 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-08 04:29 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
@ 2023-01-08 20:17 ` Karl O. Pinc <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Karl O. Pinc @ 2023-01-08 20:17 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; Andres Freund <[email protected]>; Devrim Gündüz <[email protected]>; Joe Conway <[email protected]>; pgsql-hackers
On Sat, 7 Jan 2023 22:29:35 -0600
"Karl O. Pinc" <[email protected]> wrote:
> The only way I could think of to review a patch
> that removes something is to report all the places
> I looked where a reference to the symlink might be.
I forgot to report that I also tried a `make install`
and 'make uninstall`, with no problems.
FWIW, I suspect the include/backend/postmaster/ directory
would today be named include/backend/postgres/. Now
would be the time to change the name, but I don't see
it being worth the work. And while such a change
wouldn't break pg, that kind of change would break something
for somebody.
Regards,
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply [nested|flat] 23+ messages in thread
* [PATCH v8 2/7] Row pattern recognition patch (parse/analysis).
@ 2023-09-25 05:01 Tatsuo Ishii <[email protected]>
0 siblings, 0 replies; 23+ messages in thread
From: Tatsuo Ishii @ 2023-09-25 05:01 UTC (permalink / raw)
---
src/backend/parser/parse_agg.c | 7 +
src/backend/parser/parse_clause.c | 293 +++++++++++++++++++++++++++++-
src/backend/parser/parse_expr.c | 4 +
src/backend/parser/parse_func.c | 3 +
4 files changed, 306 insertions(+), 1 deletion(-)
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index 85cd47b7ae..aa7a1cee80 100644
--- a/src/backend/parser/parse_agg.c
+++ b/src/backend/parser/parse_agg.c
@@ -564,6 +564,10 @@ check_agglevels_and_constraints(ParseState *pstate, Node *expr)
errkind = true;
break;
+ case EXPR_KIND_RPR_DEFINE:
+ errkind = true;
+ break;
+
/*
* There is intentionally no default: case here, so that the
* compiler will warn if we add a new ParseExprKind without
@@ -953,6 +957,9 @@ transformWindowFuncCall(ParseState *pstate, WindowFunc *wfunc,
case EXPR_KIND_CYCLE_MARK:
errkind = true;
break;
+ case EXPR_KIND_RPR_DEFINE:
+ errkind = true;
+ break;
/*
* There is intentionally no default: case here, so that the
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 334b9b42bd..293d4b1680 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -100,7 +100,10 @@ static WindowClause *findWindowClause(List *wclist, const char *name);
static Node *transformFrameOffset(ParseState *pstate, int frameOptions,
Oid rangeopfamily, Oid rangeopcintype, Oid *inRangeFunc,
Node *clause);
-
+static void transformRPR(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist);
+static List *transformDefineClause(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist);
+static void transformPatternClause(ParseState *pstate, WindowClause *wc, WindowDef *windef);
+static List *transformMeasureClause(ParseState *pstate, WindowClause *wc, WindowDef *windef);
/*
* transformFromClause -
@@ -2950,6 +2953,10 @@ transformWindowDefinitions(ParseState *pstate,
rangeopfamily, rangeopcintype,
&wc->endInRangeFunc,
windef->endOffset);
+
+ /* Process Row Pattern Recognition related clauses */
+ transformRPR(pstate, wc, windef, targetlist);
+
wc->runCondition = NIL;
wc->winref = winref;
@@ -3815,3 +3822,287 @@ transformFrameOffset(ParseState *pstate, int frameOptions,
return node;
}
+
+/*
+ * transformRPR
+ * Process Row Pattern Recognition related clauses
+ */
+static void
+transformRPR(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist)
+{
+ /*
+ * Window definition exists?
+ */
+ if (windef == NULL)
+ return;
+
+ /*
+ * Row Pattern Common Syntax clause exists?
+ */
+ if (windef->rpCommonSyntax == NULL)
+ return;
+
+ /* Check Frame option. Frame must start at current row */
+ if ((wc->frameOptions & FRAMEOPTION_START_CURRENT_ROW) == 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("FRAME must start at current row when row patttern recognition is used")));
+
+ /* Transform AFTER MACH SKIP TO clause */
+ wc->rpSkipTo = windef->rpCommonSyntax->rpSkipTo;
+
+ /* Transform SEEK or INITIAL clause */
+ wc->initial = windef->rpCommonSyntax->initial;
+
+ /* Transform DEFINE clause into list of TargetEntry's */
+ wc->defineClause = transformDefineClause(pstate, wc, windef, targetlist);
+
+ /* Check PATTERN clause and copy to patternClause */
+ transformPatternClause(pstate, wc, windef);
+
+ /* Transform MEASURE clause */
+ transformMeasureClause(pstate, wc, windef);
+}
+
+/*
+ * transformDefineClause Process DEFINE clause and transform ResTarget into
+ * list of TargetEntry.
+ *
+ * XXX we only support column reference in row pattern definition search
+ * condition, e.g. "price". <row pattern definition variable name>.<column
+ * reference> is not supported, e.g. "A.price".
+ */
+static List *
+transformDefineClause(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist)
+{
+ /* DEFINE variable name initials */
+ static char *defineVariableInitials = "abcdefghijklmnopqrstuvwxyz";
+
+ ListCell *lc, *l;
+ ResTarget *restarget, *r;
+ List *restargets;
+ char *name;
+ int initialLen;
+ int i;
+
+ /*
+ * If Row Definition Common Syntax exists, DEFINE clause must exist.
+ * (the raw parser should have already checked it.)
+ */
+ Assert(windef->rpCommonSyntax->rpDefs != NULL);
+
+ /*
+ * Check and add "A AS A IS TRUE" if pattern variable is missing in DEFINE
+ * per the SQL standard.
+ */
+ restargets = NIL;
+ foreach(lc, windef->rpCommonSyntax->rpPatterns)
+ {
+ A_Expr *a;
+ bool found = false;
+
+ if (!IsA(lfirst(lc), A_Expr))
+ ereport(ERROR,
+ errmsg("node type is not A_Expr"));
+
+ a = (A_Expr *)lfirst(lc);
+ name = strVal(a->lexpr);
+
+ foreach(l, windef->rpCommonSyntax->rpDefs)
+ {
+ restarget = (ResTarget *)lfirst(l);
+
+ if (!strcmp(restarget->name, name))
+ {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ {
+ /*
+ * "name" is missing. So create "name AS name IS TRUE" ResTarget
+ * node and add it to the temporary list.
+ */
+ A_Const *n;
+
+ restarget = makeNode(ResTarget);
+ n = makeNode(A_Const);
+ n->val.boolval.type = T_Boolean;
+ n->val.boolval.boolval = true;
+ n->location = -1;
+ restarget->name = pstrdup(name);
+ restarget->indirection = NIL;
+ restarget->val = (Node *)n;
+ restarget->location = -1;
+ restargets = lappend((List *)restargets, restarget);
+ }
+ }
+
+ if (list_length(restargets) >= 1)
+ {
+ /* add missing DEFINEs */
+ windef->rpCommonSyntax->rpDefs = list_concat(windef->rpCommonSyntax->rpDefs,
+ restargets);
+ list_free(restargets);
+ }
+
+ /*
+ * Check for duplicate row pattern definition variables. The standard
+ * requires that no two row pattern definition variable names shall be
+ * equivalent.
+ */
+ restargets = NIL;
+ foreach(lc, windef->rpCommonSyntax->rpDefs)
+ {
+ restarget = (ResTarget *)lfirst(lc);
+ name = restarget->name;
+
+ /*
+ * Add DEFINE expression (Restarget->val) to the targetlist as a
+ * TargetEntry if it does not exist yet. Planner will add the column
+ * ref var node to the outer plan's target list later on. This makes
+ * DEFINE expression could access the outer tuple while evaluating
+ * PATTERN.
+ *
+ * XXX: adding whole expressions of DEFINE to the plan.targetlist is
+ * not so good, because it's not necessary to evalute the expression
+ * in the target list while running the plan. We should extract the
+ * var nodes only then add them to the plan.targetlist.
+ */
+ findTargetlistEntrySQL99(pstate, (Node *)restarget->val, targetlist, EXPR_KIND_RPR_DEFINE);
+
+ /*
+ * Make sure that the row pattern definition search condition is a
+ * boolean expression.
+ */
+ transformWhereClause(pstate, restarget->val,
+ EXPR_KIND_RPR_DEFINE, "DEFINE");
+
+ foreach(l, restargets)
+ {
+ char *n;
+
+ r = (ResTarget *) lfirst(l);
+ n = r->name;
+
+ if (!strcmp(n, name))
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("row pattern definition variable name \"%s\" appears more than once in DEFINE clause",
+ name),
+ parser_errposition(pstate, exprLocation((Node *)r))));
+ }
+ restargets = lappend(restargets, restarget);
+ }
+ list_free(restargets);
+
+ /*
+ * Create list of row pattern DEFINE variable name's initial.
+ * We assign [a-z] to them (up to 26 variable names are allowed).
+ */
+ restargets = NIL;
+ i = 0;
+ initialLen = strlen(defineVariableInitials);
+
+ foreach(lc, windef->rpCommonSyntax->rpDefs)
+ {
+ char initial[2];
+
+ restarget = (ResTarget *)lfirst(lc);
+ name = restarget->name;
+
+ if (i >= initialLen)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("number of row pattern definition variable names exceeds %d", initialLen),
+ parser_errposition(pstate, exprLocation((Node *)restarget))));
+ }
+ initial[0] = defineVariableInitials[i++];
+ initial[1] = '\0';
+ wc->defineInitial = lappend(wc->defineInitial, makeString(pstrdup(initial)));
+ }
+
+ return transformTargetList(pstate, windef->rpCommonSyntax->rpDefs,
+ EXPR_KIND_RPR_DEFINE);
+}
+
+/*
+ * transformPatternClause
+ * Process PATTERN clause and return PATTERN clause in the raw parse tree
+ */
+static void
+transformPatternClause(ParseState *pstate, WindowClause *wc, WindowDef *windef)
+{
+ ListCell *lc, *l;
+
+ /*
+ * Row Pattern Common Syntax clause exists?
+ */
+ if (windef->rpCommonSyntax == NULL)
+ return;
+
+ /*
+ * Primary row pattern variable names in PATTERN clause must appear in
+ * DEFINE clause as row pattern definition variable names.
+ */
+ wc->patternVariable = NIL;
+ wc->patternRegexp = NIL;
+ foreach(lc, windef->rpCommonSyntax->rpPatterns)
+ {
+ A_Expr *a;
+ char *name;
+ char *regexp;
+ bool found = false;
+
+ if (!IsA(lfirst(lc), A_Expr))
+ ereport(ERROR,
+ errmsg("node type is not A_Expr"));
+
+ a = (A_Expr *)lfirst(lc);
+ name = strVal(a->lexpr);
+
+ foreach(l, windef->rpCommonSyntax->rpDefs)
+ {
+ ResTarget *restarget = (ResTarget *)lfirst(l);
+
+ if (!strcmp(restarget->name, name))
+ {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("primary row pattern variable name \"%s\" does not appear in DEFINE clause",
+ name),
+ parser_errposition(pstate, exprLocation((Node *)a))));
+ }
+ wc->patternVariable = lappend(wc->patternVariable, makeString(pstrdup(name)));
+ regexp = strVal(lfirst(list_head(a->name)));
+ wc->patternRegexp = lappend(wc->patternRegexp, makeString(pstrdup(regexp)));
+ }
+}
+
+/*
+ * transformMeasureClause
+ * Process MEASURE clause
+ * XXX MEASURE clause is not supported yet
+ */
+static List *
+transformMeasureClause(ParseState *pstate, WindowClause *wc, WindowDef *windef)
+{
+ if (windef->rowPatternMeasures == NIL)
+ return NIL;
+
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("%s","MEASURE clause is not supported yet"),
+ parser_errposition(pstate, exprLocation((Node *)windef->rowPatternMeasures))));
+ return NIL;
+}
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 64c582c344..18b58ac263 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -557,6 +557,7 @@ transformColumnRef(ParseState *pstate, ColumnRef *cref)
case EXPR_KIND_COPY_WHERE:
case EXPR_KIND_GENERATED_COLUMN:
case EXPR_KIND_CYCLE_MARK:
+ case EXPR_KIND_RPR_DEFINE:
/* okay */
break;
@@ -1770,6 +1771,7 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
case EXPR_KIND_VALUES:
case EXPR_KIND_VALUES_SINGLE:
case EXPR_KIND_CYCLE_MARK:
+ case EXPR_KIND_RPR_DEFINE:
/* okay */
break;
case EXPR_KIND_CHECK_CONSTRAINT:
@@ -3149,6 +3151,8 @@ ParseExprKindName(ParseExprKind exprKind)
return "GENERATED AS";
case EXPR_KIND_CYCLE_MARK:
return "CYCLE";
+ case EXPR_KIND_RPR_DEFINE:
+ return "DEFINE";
/*
* There is intentionally no default: case here, so that the
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index b3f0b6a137..2ff3699538 100644
--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c
@@ -2656,6 +2656,9 @@ check_srf_call_placement(ParseState *pstate, Node *last_srf, int location)
case EXPR_KIND_CYCLE_MARK:
errkind = true;
break;
+ case EXPR_KIND_RPR_DEFINE:
+ errkind = true;
+ break;
/*
* There is intentionally no default: case here, so that the
--
2.25.1
----Next_Part(Mon_Sep_25_14_26_30_2023_752)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v8-0003-Row-pattern-recognition-patch-planner.patch"
^ permalink raw reply [nested|flat] 23+ messages in thread
end of thread, other threads:[~2023-09-25 05:01 UTC | newest]
Thread overview: 23+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-06-18 12:51 [PATCH 5/8] Add zlib compression method Ildus Kurbangaliev <[email protected]>
2018-06-18 12:51 [PATCH 5/8] Add zlib compression method Ildus Kurbangaliev <[email protected]>
2022-03-26 05:56 Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-03-31 15:45 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-18 10:54 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-18 18:30 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-19 09:13 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-19 16:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Nathan Bossart <[email protected]>
2022-07-20 01:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 04:32 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-20 07:25 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-20 11:55 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-07-21 04:20 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Kyotaro Horiguchi <[email protected]>
2022-07-23 09:58 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Bharath Rupireddy <[email protected]>
2022-09-14 22:41 ` Re: Use "WAL segment" instead of "log segment" consistently in user-facing messages Tom Lane <[email protected]>
2023-01-07 22:59 Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-07 23:38 ` Re: drop postmaster symlink Tom Lane <[email protected]>
2023-01-08 00:33 ` Re: drop postmaster symlink Joe Conway <[email protected]>
2023-01-08 01:57 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-08 01:56 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-08 04:29 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-01-08 20:17 ` Re: drop postmaster symlink Karl O. Pinc <[email protected]>
2023-09-25 05:01 [PATCH v8 2/7] Row pattern recognition patch (parse/analysis). Tatsuo Ishii <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox