public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 01/10] Allow alternate compression methods for wal_compression
26+ messages / 7 participants
[nested] [flat]
* [PATCH 01/10] Allow alternate compression methods for wal_compression
@ 2021-02-27 04:03 Andrey Borodin <[email protected]>
0 siblings, 0 replies; 26+ messages in thread
From: Andrey Borodin @ 2021-02-27 04:03 UTC (permalink / raw)
TODO: bump XLOG_PAGE_MAGIC
---
doc/src/sgml/config.sgml | 17 +++++
src/backend/Makefile | 2 +-
src/backend/access/transam/xlog.c | 10 +++
src/backend/access/transam/xloginsert.c | 67 ++++++++++++++++---
src/backend/access/transam/xlogreader.c | 64 +++++++++++++++++-
src/backend/utils/misc/guc.c | 11 +++
src/backend/utils/misc/postgresql.conf.sample | 1 +
src/include/access/xlog.h | 1 +
src/include/access/xlog_internal.h | 16 +++++
src/include/access/xlogrecord.h | 11 ++-
10 files changed, 187 insertions(+), 13 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index a218d78bef..7fb2a84626 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3072,6 +3072,23 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-wal-compression-method" xreflabel="wal_compression_method">
+ <term><varname>wal_compressionion_method</varname> (<type>enum</type>)
+ <indexterm>
+ <primary><varname>wal_compression_method</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ This parameter selects the compression method used to compress WAL when
+ <varname>wal_compression</varname> is enabled.
+ The supported methods are pglz and zlib.
+ The default value is <literal>pglz</literal>.
+ Only superusers can change this setting.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-wal-init-zero" xreflabel="wal_init_zero">
<term><varname>wal_init_zero</varname> (<type>boolean</type>)
<indexterm>
diff --git a/src/backend/Makefile b/src/backend/Makefile
index 0da848b1fd..3af216ddfc 100644
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -48,7 +48,7 @@ OBJS = \
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/transam/xlog.c b/src/backend/access/transam/xlog.c
index f4d1ce5dea..15da91a8dd 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -99,6 +99,7 @@ bool EnableHotStandby = false;
bool fullPageWrites = true;
bool wal_log_hints = false;
bool wal_compression = false;
+int wal_compression_method = WAL_COMPRESSION_PGLZ;
char *wal_consistency_checking_string = NULL;
bool *wal_consistency_checking = NULL;
bool wal_init_zero = true;
@@ -180,6 +181,15 @@ const struct config_enum_entry recovery_target_action_options[] = {
{NULL, 0, false}
};
+/* Note that due to conditional compilation, offsets within the array are not static */
+const struct config_enum_entry wal_compression_options[] = {
+ {"pglz", WAL_COMPRESSION_PGLZ, false},
+#ifdef HAVE_LIBZ
+ {"zlib", WAL_COMPRESSION_ZLIB, false},
+#endif
+ {NULL, 0, false}
+};
+
/*
* Statistics for current checkpoint are collected in this global struct.
* Because only the checkpointer or a stand-alone backend can perform
diff --git a/src/backend/access/transam/xloginsert.c b/src/backend/access/transam/xloginsert.c
index 7052dc245e..a93b33464f 100644
--- a/src/backend/access/transam/xloginsert.c
+++ b/src/backend/access/transam/xloginsert.c
@@ -33,8 +33,18 @@
#include "storage/proc.h"
#include "utils/memutils.h"
+#ifdef HAVE_LIBZ
+#include <zlib.h>
+/* zlib compressBound is not a macro */
+#define ZLIB_MAX_BLCKSZ BLCKSZ + (BLCKSZ>>12) + (BLCKSZ>>14) + (BLCKSZ>>25) + 13
+#else
+#define ZLIB_MAX_BLCKSZ 0
+#endif
+
/* Buffer size required to store a compressed version of backup block image */
-#define PGLZ_MAX_BLCKSZ PGLZ_MAX_OUTPUT(BLCKSZ)
+#define PGLZ_MAX_BLCKSZ PGLZ_MAX_OUTPUT(BLCKSZ)
+
+#define COMPRESS_BUFSIZE Max(PGLZ_MAX_BLCKSZ, ZLIB_MAX_BLCKSZ)
/*
* For each block reference registered with XLogRegisterBuffer, we fill in
@@ -58,7 +68,7 @@ typedef struct
* backup block data in XLogRecordAssemble() */
/* buffer to store a compressed version of backup block image */
- char compressed_page[PGLZ_MAX_BLCKSZ];
+ char compressed_page[COMPRESS_BUFSIZE];
} registered_buffer;
static registered_buffer *registered_buffers;
@@ -113,7 +123,8 @@ static XLogRecData *XLogRecordAssemble(RmgrId rmid, uint8 info,
XLogRecPtr RedoRecPtr, bool doPageWrites,
XLogRecPtr *fpw_lsn, int *num_fpi);
static bool XLogCompressBackupBlock(char *page, uint16 hole_offset,
- uint16 hole_length, char *dest, uint16 *dlen);
+ uint16 hole_length, char *dest,
+ uint16 *dlen, WalCompression compression);
/*
* Begin constructing a WAL record. This must be called before the
@@ -625,16 +636,26 @@ XLogRecordAssemble(RmgrId rmid, uint8 info,
cbimg.hole_length = 0;
}
+ bimg.bimg_info = (cbimg.hole_length == 0) ? 0 : BKPIMAGE_HAS_HOLE;
+
/*
* Try to compress a block image if wal_compression is enabled
*/
if (wal_compression)
{
+ int compression;
+ /* The current compression is stored in the WAL record */
+ wal_compression_name(wal_compression_method); /* Range check */
+ compression = walmethods[wal_compression_method].walmethod;
+ Assert(compression < (1 << BKPIMAGE_COMPRESS_BITS));
+ bimg.bimg_info |=
+ compression << BKPIMAGE_COMPRESS_OFFSET_BITS;
is_compressed =
XLogCompressBackupBlock(page, bimg.hole_offset,
cbimg.hole_length,
regbuf->compressed_page,
- &compressed_len);
+ &compressed_len,
+ wal_compression_method);
}
/*
@@ -652,8 +673,6 @@ XLogRecordAssemble(RmgrId rmid, uint8 info,
rdt_datas_last->next = ®buf->bkp_rdatas[0];
rdt_datas_last = rdt_datas_last->next;
- bimg.bimg_info = (cbimg.hole_length == 0) ? 0 : BKPIMAGE_HAS_HOLE;
-
/*
* If WAL consistency checking is enabled for the resource manager
* of this WAL record, a full-page image is included in the record
@@ -827,7 +846,7 @@ XLogRecordAssemble(RmgrId rmid, uint8 info,
*/
static bool
XLogCompressBackupBlock(char *page, uint16 hole_offset, uint16 hole_length,
- char *dest, uint16 *dlen)
+ char *dest, uint16 *dlen, WalCompression compression)
{
int32 orig_len = BLCKSZ - hole_length;
int32 len;
@@ -853,12 +872,42 @@ XLogCompressBackupBlock(char *page, uint16 hole_offset, uint16 hole_length,
else
source = page;
+ switch (compression)
+ {
+ case WAL_COMPRESSION_PGLZ:
+ len = pglz_compress(source, orig_len, dest, PGLZ_strategy_default);
+ break;
+
+#ifdef HAVE_LIBZ
+ case WAL_COMPRESSION_ZLIB:
+ {
+ unsigned long len_l = COMPRESS_BUFSIZE;
+ int ret;
+ ret = compress2((Bytef*)dest, &len_l, (Bytef*)source, orig_len, 1);
+ if (ret != Z_OK)
+ len_l = -1;
+ len = len_l;
+ break;
+ }
+#endif
+
+ default:
+ /*
+ * It should be impossible to get here for unsupported algorithms,
+ * which cannot be assigned if they're not enabled at compile time.
+ */
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("unknown compression method requested: %d(%s)",
+ compression, wal_compression_name(compression))));
+
+ }
+
/*
- * We recheck the actual size even if pglz_compress() reports success and
+ * We recheck the actual size even if compression reports success and
* see if the number of bytes saved by compression is larger than the
* length of extra data needed for the compressed version of block image.
*/
- len = pglz_compress(source, orig_len, dest, PGLZ_strategy_default);
if (len >= 0 &&
len + extra_bytes < orig_len)
{
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index 42738eb940..0d8830fc50 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -33,6 +33,10 @@
#include "utils/memutils.h"
#endif
+#ifdef HAVE_LIBZ
+#include <zlib.h>
+#endif
+
static void report_invalid_record(XLogReaderState *state, const char *fmt,...)
pg_attribute_printf(2, 3);
static bool allocate_recordbuf(XLogReaderState *state, uint32 reclength);
@@ -1535,6 +1539,30 @@ XLogRecGetBlockData(XLogReaderState *record, uint8 block_id, Size *len)
}
}
+/* This is a mapping indexed by wal_compression */
+// XXX: maybe this is better done as a GUC hook to assign the 1) method; and 2) level
+struct walcompression walmethods[] = {
+ {"pglz", WAL_COMPRESSION_PGLZ},
+ {"zlib", WAL_COMPRESSION_ZLIB},
+};
+
+/*
+ * Return a statically allocated string associated with the given compression
+ * method.
+ * This is here to be visible to frontend tools like pg_rewind.
+ */
+const char *
+wal_compression_name(WalCompression compression)
+{
+ /*
+ * This could index into the guc array, except that it's compiled
+ * conditionally and unsupported methods are elided.
+ */
+ if (compression < sizeof(walmethods)/sizeof(*walmethods))
+ return walmethods[compression].name;
+ return "???";
+}
+
/*
* Restore a full-page image from a backup block attached to an XLOG record.
*
@@ -1557,9 +1585,41 @@ RestoreBlockImage(XLogReaderState *record, uint8 block_id, char *page)
if (bkpb->bimg_info & BKPIMAGE_IS_COMPRESSED)
{
+ int compression_method = BKPIMAGE_COMPRESSION(bkpb->bimg_info);
/* If a backup block image is compressed, decompress it */
- if (pglz_decompress(ptr, bkpb->bimg_len, tmp.data,
- BLCKSZ - bkpb->hole_length, true) < 0)
+ int32 decomp_result = -1;
+ switch (compression_method)
+ {
+ case WAL_COMPRESSION_PGLZ:
+ decomp_result = pglz_decompress(ptr, bkpb->bimg_len, tmp.data,
+ BLCKSZ - bkpb->hole_length, true);
+ break;
+
+#ifdef HAVE_LIBZ
+ case WAL_COMPRESSION_ZLIB:
+ {
+ unsigned long decomp_result_l;
+ decomp_result_l = BLCKSZ - bkpb->hole_length;
+ if (uncompress((Bytef*)tmp.data, &decomp_result_l,
+ (Bytef*)ptr, bkpb->bimg_len) == Z_OK)
+ decomp_result = decomp_result_l;
+ else
+ decomp_result = -1;
+ break;
+ }
+#endif
+
+ default:
+ report_invalid_record(record, "image at %X/%X is compressed with unsupported codec, block %d (%d/%s)",
+ (uint32) (record->ReadRecPtr >> 32),
+ (uint32) record->ReadRecPtr,
+ block_id,
+ compression_method,
+ wal_compression_name(compression_method));
+ return false;
+ }
+
+ if (decomp_result < 0)
{
report_invalid_record(record, "invalid compressed image at %X/%X, block %d",
LSN_FORMAT_ARGS(record->ReadRecPtr),
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 855076b1fd..8084027465 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -508,6 +508,7 @@ extern const struct config_enum_entry archive_mode_options[];
extern const struct config_enum_entry recovery_target_action_options[];
extern const struct config_enum_entry sync_method_options[];
extern const struct config_enum_entry dynamic_shared_memory_options[];
+extern const struct config_enum_entry wal_compression_options[];
/*
* GUC option variables that are exported from this module
@@ -4721,6 +4722,16 @@ static struct config_enum ConfigureNamesEnum[] =
NULL, NULL, NULL
},
+ {
+ {"wal_compression_method", PGC_SIGHUP, WAL_SETTINGS,
+ gettext_noop("Set the method used to compress full page images in the WAL."),
+ NULL
+ },
+ &wal_compression_method,
+ WAL_COMPRESSION_PGLZ, wal_compression_options,
+ NULL, NULL, NULL
+ },
+
{
{"dynamic_shared_memory_type", PGC_POSTMASTER, RESOURCES_MEM,
gettext_noop("Selects the dynamic shared memory implementation used."),
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index f46c2dd7a8..ef69a94492 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -213,6 +213,7 @@
# open_sync
#full_page_writes = on # recover from partial page writes
#wal_compression = off # enable compression of full-page writes
+#wal_compression_method = pglz # pglz, zlib
#wal_log_hints = off # also do full page writes of non-critical updates
# (change requires restart)
#wal_init_zero = on # zero-fill new WAL files
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index 6d384d3ce6..fa2e5c611f 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -117,6 +117,7 @@ extern bool EnableHotStandby;
extern bool fullPageWrites;
extern bool wal_log_hints;
extern bool wal_compression;
+extern int wal_compression_method;
extern bool wal_init_zero;
extern bool wal_recycle;
extern bool *wal_consistency_checking;
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index b23e286406..b000a21557 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -324,4 +324,20 @@ extern bool InArchiveRecovery;
extern bool StandbyMode;
extern char *recoveryRestoreCommand;
+struct walcompression
+{
+ char *name;
+ int walmethod; /* Compression method to be stored in WAL */
+};
+
+extern struct walcompression walmethods[];
+
+typedef enum WalCompression
+{
+ WAL_COMPRESSION_PGLZ,
+ WAL_COMPRESSION_ZLIB,
+} WalCompression;
+
+extern const char *wal_compression_name(WalCompression compression);
+
#endif /* XLOG_INTERNAL_H */
diff --git a/src/include/access/xlogrecord.h b/src/include/access/xlogrecord.h
index 80c92a2498..7107cf6186 100644
--- a/src/include/access/xlogrecord.h
+++ b/src/include/access/xlogrecord.h
@@ -114,7 +114,7 @@ typedef struct XLogRecordBlockHeader
* present is (BLCKSZ - <length of "hole" bytes>).
*
* Additionally, when wal_compression is enabled, we will try to compress full
- * page images using the PGLZ compression algorithm, after removing the "hole".
+ * page images, after removing the "hole".
* This can reduce the WAL volume, but at some extra cost of CPU spent
* on the compression during WAL logging. In this case, since the "hole"
* length cannot be calculated by subtracting the number of page image bytes
@@ -147,6 +147,15 @@ typedef struct XLogRecordBlockImageHeader
#define BKPIMAGE_IS_COMPRESSED 0x02 /* page image is compressed */
#define BKPIMAGE_APPLY 0x04 /* page image should be restored during
* replay */
+#define BKPIMAGE_COMPRESS_METHOD1 0x08 /* bits to encode compression method */
+#define BKPIMAGE_COMPRESS_METHOD2 0x10 /* 0=pglz; 1=zlib; */
+
+/* How many bits to shift to extract compression */
+#define BKPIMAGE_COMPRESS_OFFSET_BITS 3
+/* How many bits are for compression */
+#define BKPIMAGE_COMPRESS_BITS 2
+/* Extract the compression from the bimg_info */
+#define BKPIMAGE_COMPRESSION(info) ((info >> BKPIMAGE_COMPRESS_OFFSET_BITS) & ((1<<BKPIMAGE_COMPRESS_BITS) - 1))
/*
* Extra header information used when page image has "hole" and
--
2.17.0
--jozmn01XJZjDjM3N
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="0002-Run-011_crash_recovery.pl-with-wal_level-minimal.patch"
^ permalink raw reply [nested|flat] 26+ messages in thread
* more descriptive message for process termination due to max_slot_wal_keep_size
@ 2021-12-14 04:04 Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-14 14:13 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Bharath Rupireddy <[email protected]>
0 siblings, 2 replies; 26+ messages in thread
From: Kyotaro Horiguchi @ 2021-12-14 04:04 UTC (permalink / raw)
To: pgsql-hackers
Hello.
As complained in pgsql-bugs [1], when a process is terminated due to
max_slot_wal_keep_size, the related messages don't mention the root
cause for *the termination*. Note that the third message does not
show for temporary replication slots.
[pid=a] LOG: terminating process x to release replication slot "s"
[pid=x] LOG: FATAL: terminating connection due to administrator command
[pid=a] LOG: invalidting slot "s" because its restart_lsn X/X exceeds max_slot_wal_keep_size
The attached patch attaches a DETAIL line to the first message.
> [17605] LOG: terminating process 17614 to release replication slot "s1"
+ [17605] DETAIL: The slot's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> [17614] FATAL: terminating connection due to administrator command
> [17605] LOG: invalidating slot "s1" because its restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size
Somewhat the second and fourth lines look inconsistent each other but
that wouldn't be such a problem. I don't think we want to concatenate
the two lines together as the result is a bit too long.
> LOG: terminating process 17614 to release replication slot "s1" because it's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
What do you think about this?
[1] https://www.postgresql.org/message-id/20211214.101137.379073733372253470.horikyota.ntt%40gmail.com
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2021-12-14 14:01 ` Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
1 sibling, 1 reply; 26+ messages in thread
From: Ashutosh Bapat @ 2021-12-14 14:01 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: pgsql-hackers
On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
<[email protected]> wrote:
>
> Hello.
>
> As complained in pgsql-bugs [1], when a process is terminated due to
> max_slot_wal_keep_size, the related messages don't mention the root
> cause for *the termination*. Note that the third message does not
> show for temporary replication slots.
>
> [pid=a] LOG: terminating process x to release replication slot "s"
> [pid=x] LOG: FATAL: terminating connection due to administrator command
> [pid=a] LOG: invalidting slot "s" because its restart_lsn X/X exceeds max_slot_wal_keep_size
>
> The attached patch attaches a DETAIL line to the first message.
>
> > [17605] LOG: terminating process 17614 to release replication slot "s1"
> + [17605] DETAIL: The slot's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> > [17614] FATAL: terminating connection due to administrator command
> > [17605] LOG: invalidating slot "s1" because its restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size
>
> Somewhat the second and fourth lines look inconsistent each other but
> that wouldn't be such a problem. I don't think we want to concatenate
> the two lines together as the result is a bit too long.
>
> > LOG: terminating process 17614 to release replication slot "s1" because it's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
>
> What do you think about this?
Agree. I think we should also specify the restart_lsn value which
would be within max_slot_wal_keep_size for better understanding.
--
Best Wishes,
Ashutosh Bapat
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
@ 2021-12-15 04:12 ` Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2021-12-15 04:12 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-hackers
At Tue, 14 Dec 2021 19:31:21 +0530, Ashutosh Bapat <[email protected]> wrote in
> On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
> <[email protected]> wrote:
> > > [17605] LOG: terminating process 17614 to release replication slot "s1"
> > + [17605] DETAIL: The slot's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> > > [17614] FATAL: terminating connection due to administrator command
> > > [17605] LOG: invalidating slot "s1" because its restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size
> >
> > Somewhat the second and fourth lines look inconsistent each other but
> > that wouldn't be such a problem. I don't think we want to concatenate
> > the two lines together as the result is a bit too long.
> >
> > > LOG: terminating process 17614 to release replication slot "s1" because it's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> >
> > What do you think about this?
>
> Agree. I think we should also specify the restart_lsn value which
> would be within max_slot_wal_keep_size for better understanding.
Thanks! It seems to me the main message of the "invalidating" log has
no room for further detail. So I split the reason out to DETAILS line
the same way with the "terminating" message in the attached second
patch. (It is separated from the first patch just for review) I
believe someone can make the DETAIL message simpler or more natural.
The attached patch set emits the following message.
> LOG: invalidating slot "s1"
> DETAIL: The slot's restart_lsn 0/10000D68 is behind the limit 0/11000000 defined by max_slot_wal_keep_size.
The second line could be changed like the following or anything other.
> DETAIL: The slot's restart_lsn 0/10000D68 got behind the limit 0/11000000 determined by max_slot_wal_keep_size.
.....
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2021-12-23 12:38 ` Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Ashutosh Bapat @ 2021-12-23 12:38 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: pgsql-hackers
On Wed, Dec 15, 2021 at 9:42 AM Kyotaro Horiguchi
<[email protected]> wrote:
>
> At Tue, 14 Dec 2021 19:31:21 +0530, Ashutosh Bapat <[email protected]> wrote in
> > On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
> > <[email protected]> wrote:
> > > > [17605] LOG: terminating process 17614 to release replication slot "s1"
> > > + [17605] DETAIL: The slot's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> > > > [17614] FATAL: terminating connection due to administrator command
> > > > [17605] LOG: invalidating slot "s1" because its restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size
> > >
> > > Somewhat the second and fourth lines look inconsistent each other but
> > > that wouldn't be such a problem. I don't think we want to concatenate
> > > the two lines together as the result is a bit too long.
> > >
> > > > LOG: terminating process 17614 to release replication slot "s1" because it's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> > >
> > > What do you think about this?
> >
> > Agree. I think we should also specify the restart_lsn value which
> > would be within max_slot_wal_keep_size for better understanding.
>
> Thanks! It seems to me the main message of the "invalidating" log has
> no room for further detail. So I split the reason out to DETAILS line
> the same way with the "terminating" message in the attached second
> patch. (It is separated from the first patch just for review) I
> believe someone can make the DETAIL message simpler or more natural.
>
> The attached patch set emits the following message.
>
> > LOG: invalidating slot "s1"
> > DETAIL: The slot's restart_lsn 0/10000D68 is behind the limit 0/11000000 defined by max_slot_wal_keep_size.
>
> The second line could be changed like the following or anything other.
>
> > DETAIL: The slot's restart_lsn 0/10000D68 got behind the limit 0/11000000 determined by max_slot_wal_keep_size.
> .....
>
The second version looks better as it gives more details. I am fine
with either of the above wordings.
I would prefer everything in the same message though since
"invalidating slot ..." is too short a LOG message. Not everybody
enabled details always.
--
Best Wishes,
Ashutosh Bapat
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
@ 2021-12-24 04:42 ` Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2021-12-24 04:42 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-hackers
At Thu, 23 Dec 2021 18:08:08 +0530, Ashutosh Bapat <[email protected]> wrote in
> On Wed, Dec 15, 2021 at 9:42 AM Kyotaro Horiguchi
> <[email protected]> wrote:
> > > LOG: invalidating slot "s1"
> > > DETAIL: The slot's restart_lsn 0/10000D68 is behind the limit 0/11000000 defined by max_slot_wal_keep_size.
> >
> > The second line could be changed like the following or anything other.
> >
> > > DETAIL: The slot's restart_lsn 0/10000D68 got behind the limit 0/11000000 determined by max_slot_wal_keep_size.
> > .....
> >
>
> The second version looks better as it gives more details. I am fine
> with either of the above wordings.
>
> I would prefer everything in the same message though since
> "invalidating slot ..." is too short a LOG message. Not everybody
> enabled details always.
Mmm. Right. I have gone too much to the same way with the
process-termination message.
I rearranged the meesages as follows in the attached version. (at master)
> LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
> DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
> LOG: invalidating slot \"%s\" because its restart_LSN %X/%X exceeds max_slot_wal_keep_size
c> DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
The messages is actually incomplete even in 13 so I think the change
to the errmsg() message of the first message is worth back-patching.
- v3-0001-Make-a-message-on-process-termination-more-dscrip.patch
Changes only the first main message and it can be back-patched to 14.
- v3-0001-Make-a-message-on-process-termination-more-dscrip_13.patch
The same to the above but for 13, which doesn't have LSN_FORMAT_ARGS.
- v3-0002-Add-detailed-information-to-slot-invalidation-mes.patch
Attaches the DETAIL line shown above to both messages, only for the
master.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2021-12-24 08:06 ` Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-12-24 08:06 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; pgsql-hackers
On Fri, Dec 24, 2021 at 1:42 PM Kyotaro Horiguchi
<[email protected]> wrote:
>
> At Thu, 23 Dec 2021 18:08:08 +0530, Ashutosh Bapat <[email protected]> wrote in
> > On Wed, Dec 15, 2021 at 9:42 AM Kyotaro Horiguchi
> > <[email protected]> wrote:
> > > > LOG: invalidating slot "s1"
> > > > DETAIL: The slot's restart_lsn 0/10000D68 is behind the limit 0/11000000 defined by max_slot_wal_keep_size.
> > >
> > > The second line could be changed like the following or anything other.
> > >
> > > > DETAIL: The slot's restart_lsn 0/10000D68 got behind the limit 0/11000000 determined by max_slot_wal_keep_size.
> > > .....
> > >
> >
> > The second version looks better as it gives more details. I am fine
> > with either of the above wordings.
> >
> > I would prefer everything in the same message though since
> > "invalidating slot ..." is too short a LOG message. Not everybody
> > enabled details always.
>
> Mmm. Right. I have gone too much to the same way with the
> process-termination message.
>
> I rearranged the meesages as follows in the attached version. (at master)
Thank you for the patch! +1 for improving the messages.
>
> > LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
> > DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
>
> > LOG: invalidating slot \"%s\" because its restart_LSN %X/%X exceeds max_slot_wal_keep_size
> c> DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
-
LSN_FORMAT_ARGS(restart_lsn))));
+
LSN_FORMAT_ARGS(restart_lsn)),
+ errdetail("The slot
got behind the limit %X/%X determined by max_slot_wal_keep_size.",
+
LSN_FORMAT_ARGS(oldestLSN))));
Isn't oldestLSN calculated not only by max_slot_wal_keep_size but also
by wal_keep_size?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
@ 2021-12-24 08:30 ` Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2021-12-24 08:30 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; pgsql-hackers
Thank you for the comment.
At Fri, 24 Dec 2021 17:06:57 +0900, Masahiko Sawada <[email protected]> wrote in
> Thank you for the patch! +1 for improving the messages.
>
> >
> > > LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
> > > DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
> >
> > > LOG: invalidating slot \"%s\" because its restart_LSN %X/%X exceeds max_slot_wal_keep_size
> > c> DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
>
> -
> LSN_FORMAT_ARGS(restart_lsn))));
> +
> LSN_FORMAT_ARGS(restart_lsn)),
> + errdetail("The slot
> got behind the limit %X/%X determined by max_slot_wal_keep_size.",
> +
> LSN_FORMAT_ARGS(oldestLSN))));
>
> Isn't oldestLSN calculated not only by max_slot_wal_keep_size but also
> by wal_keep_size?
Right. But I believe the two are not assumed to be used at once. One
can set wal_keep_size larger than max_slot_wal_keep_size but it is
actually a kind of ill setting.
LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size and wal_keep_size.
Mmm. I don't like this. I feel we don't need such detail in the
message.. I'd like to hear opinions from others, please.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2021-12-24 11:23 ` Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-12-24 11:23 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; pgsql-hackers
On Fri, Dec 24, 2021 at 5:30 PM Kyotaro Horiguchi
<[email protected]> wrote:
>
> Thank you for the comment.
>
> At Fri, 24 Dec 2021 17:06:57 +0900, Masahiko Sawada <[email protected]> wrote in
> > Thank you for the patch! +1 for improving the messages.
> >
> > >
> > > > LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
> > > > DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
> > >
> > > > LOG: invalidating slot \"%s\" because its restart_LSN %X/%X exceeds max_slot_wal_keep_size
> > > c> DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size.
> >
> > -
> > LSN_FORMAT_ARGS(restart_lsn))));
> > +
> > LSN_FORMAT_ARGS(restart_lsn)),
> > + errdetail("The slot
> > got behind the limit %X/%X determined by max_slot_wal_keep_size.",
> > +
> > LSN_FORMAT_ARGS(oldestLSN))));
> >
> > Isn't oldestLSN calculated not only by max_slot_wal_keep_size but also
> > by wal_keep_size?
>
> Right. But I believe the two are not assumed to be used at once. One
> can set wal_keep_size larger than max_slot_wal_keep_size but it is
> actually a kind of ill setting.
>
> LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
> DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size and wal_keep_size.
>
> Mmm. I don't like this. I feel we don't need such detail in the
> message.
How about something like:
LOG: terminating process %d to release replication slot \"%s\"
because its restart_lsn %X/%X exceeds the limit
DETAIL: The slot got behind the limit %X/%X
HINT: You might need to increase max_slot_wal_keep_size or wal_keep_size.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
@ 2022-01-04 01:29 ` Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-01-04 01:29 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; pgsql-hackers
At Fri, 24 Dec 2021 20:23:29 +0900, Masahiko Sawada <[email protected]> wrote in
> On Fri, Dec 24, 2021 at 5:30 PM Kyotaro Horiguchi
> <[email protected]> wrote:
> > Right. But I believe the two are not assumed to be used at once. One
> > can set wal_keep_size larger than max_slot_wal_keep_size but it is
> > actually a kind of ill setting.
> >
> > LOG: terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size
> > DETAIL: The slot got behind the limit %X/%X determined by max_slot_wal_keep_size and wal_keep_size.
> >
> > Mmm. I don't like this. I feel we don't need such detail in the
> > message.
>
> How about something like:
>
> LOG: terminating process %d to release replication slot \"%s\"
> because its restart_lsn %X/%X exceeds the limit
> DETAIL: The slot got behind the limit %X/%X
> HINT: You might need to increase max_slot_wal_keep_size or wal_keep_size.
The message won't be seen when max_slot_wal_keep_size is not set. So
we don't recommend to increase wal_keep_size in that case. We might
need inhibit (or warn)the two parameters from being activated at once,
but it would be another issue.
Another point is how people determine the value for the parameter. I
suppose (or believe) max_slot_wal_keep_size is not a kind to set to
minimal first then increase later but a kind to set to maximum
allowable first. On the other hand we suggest as the follows for
too-small max_wal_size so we could do the same for this parameter.
> HINT: Consider increasing the configuration parameter \"max_wal_size\".
Also, I don't like we have three lines for this message. If the DETAIL
adds only the specific value of the limit, I think it'd better append
it to the main message.
So what do you say if I propose the following?
LOG: terminating process %d to release replication slot \"%s\"
because its restart_lsn %X/%X exceeds the limit %X/%X
HINT: You might need to increase max_slot_wal_keep_size.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-03-02 06:37 ` Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-03-02 06:37 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; pgsql-hackers
At Tue, 04 Jan 2022 10:29:31 +0900 (JST), Kyotaro Horiguchi <[email protected]> wrote in
> So what do you say if I propose the following?
>
> LOG: terminating process %d to release replication slot \"%s\"
> because its restart_lsn %X/%X exceeds the limit %X/%X
> HINT: You might need to increase max_slot_wal_keep_size.
This version emits the following message.
[35785:checkpointer] LOG: terminating process 36368 to release replication slot "s1" because its restart_lsn 0/1F000148 exceeds the limit 0/21000000
[35785:checkpointer] HINT: You might need to increase max_slot_wal_keep_size.
[36368:walsender] FATAL: terminating connection due to administrator command
[36368:walsender] STATEMENT: START_REPLICATION SLOT "s1" 0/1F000000 TIMELINE 1
[35785:checkpointer] LOG: invalidating slot "s1" because its restart_lsn 0/1F000148 exceeds the limit 0/21000000
[35785:checkpointer] HINT: You might need to increase max_slot_wal_keep_size.
We can omit the HINT line from the termination log for non-persistent
slots but I think we don't want to bother that considering its low
frequency.
The CI was confused by the mixed patches for multiple PG versions. In
this version the patchset for master are attached as .patch and that
for PG13 as .txt.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From 6c5a680842521b26c0c899c3d0675bd53e58ac11 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <[email protected]>
Date: Fri, 24 Dec 2021 13:23:54 +0900
Subject: [PATCH v4] Make a message on process termination more dscriptive
The message at process termination due to slot limit doesn't provide
the reason. In the major scenario the message is followed by another
message about slot invalidatation, which shows the detail for the
termination. However the second message is missing if the slot is
temporary one.
Augment the first message with the reason same as the second message.
Backpatch through to 13 where the message was introduced.
Reported-by: Alex Enachioaie <[email protected]>
Author: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Ashutosh Bapat <[email protected]>
Reviewed-by: Bharath Rupireddy <[email protected]>
Discussion: https://www.postgresql.org/message-id/17327-89d0efa8b9ae6271%40postgresql.org
Backpatch-through: 13
---
src/backend/replication/slot.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 02047ea920..15b8934ae2 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1228,8 +1228,10 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
if (last_signaled_pid != active_pid)
{
ereport(LOG,
- (errmsg("terminating process %d to release replication slot \"%s\"",
- active_pid, NameStr(slotname))));
+ (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size",
+ active_pid, NameStr(slotname),
+ (uint32) (restart_lsn >> 32),
+ (uint32) restart_lsn)));
(void) kill(active_pid, SIGTERM);
last_signaled_pid = active_pid;
--
2.27.0
Attachments:
[text/x-patch] v4-0001-Make-a-message-on-process-termination-more-dscrip.patch (1.8K, ../../[email protected]/2-v4-0001-Make-a-message-on-process-termination-more-dscrip.patch)
download | inline diff:
From 4909db2893f0b33ab6bca1ffc3ad802cd159c577 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <[email protected]>
Date: Fri, 24 Dec 2021 12:52:07 +0900
Subject: [PATCH v4 1/2] Make a message on process termination more dscriptive
The message at process termination due to slot limit doesn't provide
the reason. In the major scenario the message is followed by another
message about slot invalidatation, which shows the detail for the
termination. However the second message is missing if the slot is
temporary one.
Augment the first message with the reason same as the second message.
Backpatch through to 13 where the message was introduced.
Reported-by: Alex Enachioaie <[email protected]>
Author: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Ashutosh Bapat <[email protected]>
Reviewed-by: Bharath Rupireddy <[email protected]>
Discussion: https://www.postgresql.org/message-id/17327-89d0efa8b9ae6271%40postgresql.org
Backpatch-through: 13
---
src/backend/replication/slot.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index caa6b29756..92f19bcb35 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1300,8 +1300,9 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
if (last_signaled_pid != active_pid)
{
ereport(LOG,
- (errmsg("terminating process %d to release replication slot \"%s\"",
- active_pid, NameStr(slotname))));
+ (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size",
+ active_pid, NameStr(slotname),
+ LSN_FORMAT_ARGS(restart_lsn))));
(void) kill(active_pid, SIGTERM);
last_signaled_pid = active_pid;
--
2.27.0
[text/x-patch] v4-0002-Add-detailed-information-to-slot-invalidation-mes.patch (2.3K, ../../[email protected]/3-v4-0002-Add-detailed-information-to-slot-invalidation-mes.patch)
download | inline diff:
From f31014f85c7dec160bd42e1c48f1c28a7dc22af2 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <[email protected]>
Date: Fri, 24 Dec 2021 12:58:25 +0900
Subject: [PATCH v4 2/2] Add detailed information to slot-invalidation messages
The messages says just "exceeds max_slot_wal_keep_size" but doesn't
tell the concrete LSN of the limit. That information helps operators'
understanding on the issue.
Author: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Ashutosh Bapat <[email protected]>
Reviewed-by: Masahiko Sawada <[email protected]>
Discussion: https://www.postgresql.org/message-id/17327-89d0efa8b9ae6271%40postgresql.org
---
src/backend/replication/slot.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 92f19bcb35..be21b62add 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1300,9 +1300,11 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
if (last_signaled_pid != active_pid)
{
ereport(LOG,
- (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size",
+ (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit %X/%X",
active_pid, NameStr(slotname),
- LSN_FORMAT_ARGS(restart_lsn))));
+ LSN_FORMAT_ARGS(restart_lsn),
+ LSN_FORMAT_ARGS(oldestLSN)),
+ errhint("You might need to increase max_slot_wal_keep_size.")));
(void) kill(active_pid, SIGTERM);
last_signaled_pid = active_pid;
@@ -1345,9 +1347,11 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
ReplicationSlotRelease();
ereport(LOG,
- (errmsg("invalidating slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size",
+ (errmsg("invalidating slot \"%s\" because its restart_lsn %X/%X exceeds the limit %X/%X",
NameStr(slotname),
- LSN_FORMAT_ARGS(restart_lsn))));
+ LSN_FORMAT_ARGS(restart_lsn),
+ LSN_FORMAT_ARGS(oldestLSN)),
+ errhint("You might need to increase max_slot_wal_keep_size.")));
/* done with this slot for now */
break;
--
2.27.0
[text/plain] v4-0001-Make-a-message-on-process-termination-more-dscrip_13.txt (1.9K, ../../[email protected]/4-v4-0001-Make-a-message-on-process-termination-more-dscrip_13.txt)
download | inline diff:
From 6c5a680842521b26c0c899c3d0675bd53e58ac11 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <[email protected]>
Date: Fri, 24 Dec 2021 13:23:54 +0900
Subject: [PATCH v4] Make a message on process termination more dscriptive
The message at process termination due to slot limit doesn't provide
the reason. In the major scenario the message is followed by another
message about slot invalidatation, which shows the detail for the
termination. However the second message is missing if the slot is
temporary one.
Augment the first message with the reason same as the second message.
Backpatch through to 13 where the message was introduced.
Reported-by: Alex Enachioaie <[email protected]>
Author: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Ashutosh Bapat <[email protected]>
Reviewed-by: Bharath Rupireddy <[email protected]>
Discussion: https://www.postgresql.org/message-id/17327-89d0efa8b9ae6271%40postgresql.org
Backpatch-through: 13
---
src/backend/replication/slot.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 02047ea920..15b8934ae2 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1228,8 +1228,10 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
if (last_signaled_pid != active_pid)
{
ereport(LOG,
- (errmsg("terminating process %d to release replication slot \"%s\"",
- active_pid, NameStr(slotname))));
+ (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size",
+ active_pid, NameStr(slotname),
+ (uint32) (restart_lsn >> 32),
+ (uint32) restart_lsn)));
(void) kill(active_pid, SIGTERM);
last_signaled_pid = active_pid;
--
2.27.0
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-05 09:56 ` Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Drouvot, Bertrand @ 2022-09-05 09:56 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; [email protected]; +Cc: [email protected]; pgsql-hackers
Hi,
On 3/2/22 7:37 AM, Kyotaro Horiguchi wrote:
> At Tue, 04 Jan 2022 10:29:31 +0900 (JST), Kyotaro Horiguchi<[email protected]> wrote in
>> So what do you say if I propose the following?
>>
>> LOG: terminating process %d to release replication slot \"%s\"
>> because its restart_lsn %X/%X exceeds the limit %X/%X
>> HINT: You might need to increase max_slot_wal_keep_size.
> This version emits the following message.
>
> [35785:checkpointer] LOG: terminating process 36368 to release replication slot "s1" because its restart_lsn 0/1F000148 exceeds the limit 0/21000000
> [35785:checkpointer] HINT: You might need to increase max_slot_wal_keep_size.
As the hint is to increase max_slot_wal_keep_size, what about reporting
the difference in size (rather than the limit lsn)? Something along
those lines?
[35785:checkpointer] LOG: terminating process 36368 to release replication slot "s1" because its restart_lsn 0/1F000148 exceeds the limit by <NNN MB>.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services:https://aws.amazon.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
@ 2022-09-06 05:53 ` Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-06 05:53 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; pgsql-hackers
At Mon, 5 Sep 2022 11:56:33 +0200, "Drouvot, Bertrand" <[email protected]> wrote in
> Hi,
>
> On 3/2/22 7:37 AM, Kyotaro Horiguchi wrote:
> > At Tue, 04 Jan 2022 10:29:31 +0900 (JST), Kyotaro
> > Horiguchi<[email protected]> wrote in
> >> So what do you say if I propose the following?
> >>
> >> LOG: terminating process %d to release replication slot \"%s\"
> >> because its restart_lsn %X/%X exceeds the limit %X/%X
> >> HINT: You might need to increase max_slot_wal_keep_size.
> > This version emits the following message.
> >
> > [35785:checkpointer] LOG: terminating process 36368 to release
> > replication slot "s1" because its restart_lsn 0/1F000148 exceeds the
> > limit 0/21000000
> > [35785:checkpointer] HINT: You might need to increase
> > max_slot_wal_keep_size.
>
> As the hint is to increase max_slot_wal_keep_size, what about
> reporting the difference in size (rather than the limit lsn)?
> Something along those lines?
>
> [35785:checkpointer] LOG: terminating process 36368 to release
> replication slot "s1" because its restart_lsn 0/1F000148 exceeds the
> limit by <NNN MB>.
Thanks! That might be more sensible exactly for the reason you
mentioned. One issue doing that is size_pretty is dbsize.c local
function. Since the size is less than kB in many cases, we cannot use
fixed unit for that.
0001 and 0002 are the same with v5.
0003 exposes byte_size_pretty() to other modules.
0004 does the change by using byte_size_pretty()
After 0004 applied, they look like this.
> LOG: terminating process 108413 to release replication slot "rep3" because its restart_lsn 0/7000D8 exceeds the limit by 1024 kB
> HINT: You might need to increase max_slot_wal_keep_size.
The reason for "1024 kB" instead of "1 MB" is the precise value is a
bit less than 1024 * 1024.
regards.
-
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-06 08:54 ` Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Drouvot, Bertrand @ 2022-09-06 08:54 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; pgsql-hackers
Hi,
On 9/6/22 7:53 AM, Kyotaro Horiguchi wrote:
> At Mon, 5 Sep 2022 11:56:33 +0200, "Drouvot, Bertrand"<[email protected]> wrote in
>> Hi,
>>
>> On 3/2/22 7:37 AM, Kyotaro Horiguchi wrote:
>>> At Tue, 04 Jan 2022 10:29:31 +0900 (JST), Kyotaro
>>> Horiguchi<[email protected]> wrote in
>>>> So what do you say if I propose the following?
>>>>
>>>> LOG: terminating process %d to release replication slot \"%s\"
>>>> because its restart_lsn %X/%X exceeds the limit %X/%X
>>>> HINT: You might need to increase max_slot_wal_keep_size.
>>> This version emits the following message.
>>>
>>> [35785:checkpointer] LOG: terminating process 36368 to release
>>> replication slot "s1" because its restart_lsn 0/1F000148 exceeds the
>>> limit 0/21000000
>>> [35785:checkpointer] HINT: You might need to increase
>>> max_slot_wal_keep_size.
>> As the hint is to increase max_slot_wal_keep_size, what about
>> reporting the difference in size (rather than the limit lsn)?
>> Something along those lines?
>>
>> [35785:checkpointer] LOG: terminating process 36368 to release
>> replication slot "s1" because its restart_lsn 0/1F000148 exceeds the
>> limit by <NNN MB>.
> Thanks! That might be more sensible exactly for the reason you
> mentioned. One issue doing that is size_pretty is dbsize.c local
> function. Since the size is less than kB in many cases, we cannot use
> fixed unit for that.
Thanks for the new patch version!. I did not realized (sorry about that)
that we'd need to expose byte_size_pretty(). Now I wonder if we should
not simply report the number of bytes (like I can see it is done in many
places). So something like:
@@ -1298,9 +1298,9 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s,
XLogRecPtr oldestLSN,
byte_size_pretty(buf, sizeof(buf),
oldestLSN - restart_lsn);
ereport(LOG,
- (errmsg("terminating process %d to release replication slot \"%s\"
because its restart_lsn %X/%X exceeds the limit by %s",
+ (errmsg("terminating process %d to release replication slot \"%s\"
because its restart_lsn %X/%X exceeds the limit by %lu bytes",
active_pid, NameStr(slotname),
- LSN_FORMAT_ARGS(restart_lsn), buf),
+ LSN_FORMAT_ARGS(restart_lsn), oldestLSN - restart_lsn),
errhint("You might
need to increase max_slot_wal_keep_size.")));
and then forget about exposing/using byte_size_pretty() (that would be
more consistent with the same kind of reporting in the existing code).
What do you think?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services:https://aws.amazon.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
@ 2022-09-07 02:20 ` Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-07 02:20 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; pgsql-hackers
(I noticed I sent a wrong version..)
At Tue, 6 Sep 2022 10:54:35 +0200, "Drouvot, Bertrand" <[email protected]> wrote in
> Thanks for the new patch version!. I did not realized (sorry about
> that) that we'd need to expose byte_size_pretty(). Now I wonder if we
I didn't think we need the units larger than MB, but I used
pretty_print to prevent small number from rounding to exactly zero. On
the other hand, in typical cases it is longer than 6 digits in bytes,
which is a bit hard to read a glance.
> LOG: terminating process 16034 to release replication slot "rep1" because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
> should not simply report the number of bytes (like I can see it is
> done in many places). So something like:
..
> + (errmsg("terminating process %d to release replication slot \"%s\"
> because its restart_lsn %X/%X exceeds the limit by %lu bytes",
..
> and then forget about exposing/using byte_size_pretty() (that would be
> more consistent with the same kind of reporting in the existing code).
>
> What do you think?
An alterntive would be rounding up to the whole MB, or a sub-MB.
> ereport(LOG,
> (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit by %.1lf MB",
> active_pid, NameStr(slotname),
> LSN_FORMAT_ARGS(restart_lsn),
> /* round-up at sub-MB */
> ceil((double) (oldestLSN - restart_lsn) / 1024 / 102.4) / 10),
> LOG: terminating process 49539 to release replication slot "rep1" because its restart_lsn 0/3038000 exceeds the limit by 15.8 MB
If the distance were 1 byte, it is shown as "0.1 MB".
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-07 10:16 ` Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Drouvot, Bertrand @ 2022-09-07 10:16 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; pgsql-hackers
Hi,
On 9/7/22 4:20 AM, Kyotaro Horiguchi wrote:
> (I noticed I sent a wrong version..)
>
> At Tue, 6 Sep 2022 10:54:35 +0200, "Drouvot, Bertrand"<[email protected]> wrote in
>> Thanks for the new patch version!. I did not realized (sorry about
>> that) that we'd need to expose byte_size_pretty(). Now I wonder if we
> I didn't think we need the units larger than MB, but I used
> pretty_print to prevent small number from rounding to exactly zero.
Yeah makes sense.
Also, rounding to zero wouldn't occur with "just" displaying "oldestLSN
- restart_lsn" (as proposed upthread).
> On
> the other hand, in typical cases it is longer than 6 digits in bytes,
> which is a bit hard to read a glance.
Yeah right, but that's already the case in some part of the code, like
for example in arrayfuncs.c:
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("array size exceeds the maximum allowed
(%d)",
(int) MaxAllocSize)));
>> LOG: terminating process 16034 to release replication slot "rep1" because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
>> should not simply report the number of bytes (like I can see it is
>> done in many places). So something like:
> ..
>> + (errmsg("terminating process %d to release replication slot \"%s\"
>> because its restart_lsn %X/%X exceeds the limit by %lu bytes",
> ..
>> and then forget about exposing/using byte_size_pretty() (that would be
>> more consistent with the same kind of reporting in the existing code).
>>
>> What do you think?
> An alterntive would be rounding up to the whole MB, or a sub-MB.
>
>> ereport(LOG,
>> (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit by %.1lf MB",
>> active_pid, NameStr(slotname),
>> LSN_FORMAT_ARGS(restart_lsn),
>> /* round-up at sub-MB */
>> ceil((double) (oldestLSN - restart_lsn) / 1024 / 102.4) / 10),
typo "/ 102.4" ?
>> LOG: terminating process 49539 to release replication slot "rep1" because its restart_lsn 0/3038000 exceeds the limit by 15.8 MB
> If the distance were 1 byte, it is shown as "0.1 MB".
Right and I'm -1 on it, I think we should stick to the "pretty" or the
"bytes only" approach (my preference being the bytes only one).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services:https://aws.amazon.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
@ 2022-09-08 04:40 ` Kyotaro Horiguchi <[email protected]>
2022-09-08 09:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
0 siblings, 2 replies; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-08 04:40 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; pgsql-hackers
At Wed, 7 Sep 2022 12:16:29 +0200, "Drouvot, Bertrand" <[email protected]> wrote in
> Also, rounding to zero wouldn't occur with "just" displaying
> "oldestLSN - restart_lsn" (as proposed upthread).
..
> Yeah right, but that's already the case in some part of the code, like
> for example in arrayfuncs.c:
Fair points.
> >> ereport(LOG,
> >> (errmsg("terminating process %d to release replication slot
> >> \"%s\" because its restart_lsn %X/%X exceeds the limit by %.1lf
> >> MB",
> >> active_pid, NameStr(slotname),
> >> LSN_FORMAT_ARGS(restart_lsn),
> >> /* round-up at sub-MB */
> >> ceil((double) (oldestLSN - restart_lsn) / 1024 / 102.4) /
> >> 10),
>
> typo "/ 102.4" ?
No, it rounds the difference up to one decimal place. So it is devided
by 10 after ceil():p
> >> LOG: terminating process 49539 to release replication slot "rep1"
> >> because its restart_lsn 0/3038000 exceeds the limit by 15.8 MB
> > If the distance were 1 byte, it is shown as "0.1 MB".
>
> Right and I'm -1 on it, I think we should stick to the "pretty" or the
> "bytes only" approach (my preference being the bytes only one).
Okay. the points you brought up above are sufficient grounds for not
doing so. Now they are in the following format.
>> LOG: terminating process 16034 to release replication slot "rep1"
>> because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
Thank you for the discussion, Bertrand!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-08 09:29 ` Drouvot, Bertrand <[email protected]>
1 sibling, 0 replies; 26+ messages in thread
From: Drouvot, Bertrand @ 2022-09-08 09:29 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; pgsql-hackers
Hi,
On 9/8/22 6:40 AM, Kyotaro Horiguchi wrote:
> At Wed, 7 Sep 2022 12:16:29 +0200, "Drouvot, Bertrand"<[email protected]> wrote in
>>>> LOG: terminating process 49539 to release replication slot "rep1"
>>>> because its restart_lsn 0/3038000 exceeds the limit by 15.8 MB
>>> If the distance were 1 byte, it is shown as "0.1 MB".
>> Right and I'm -1 on it, I think we should stick to the "pretty" or the
>> "bytes only" approach (my preference being the bytes only one).
> Okay. the points you brought up above are sufficient grounds for not
> doing so. Now they are in the following format.
>
>>> LOG: terminating process 16034 to release replication slot "rep1"
>>> because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
> Thank you for the discussion, Bertrand!
You are welcome, thanks for the patch!
It looks good to me, barring any objections i think we can mark the CF
entry as Ready for Committer.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services:https://aws.amazon.com
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-28 20:30 ` Tom Lane <[email protected]>
2022-09-28 20:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-29 05:27 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
1 sibling, 2 replies; 26+ messages in thread
From: Tom Lane @ 2022-09-28 20:30 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
Kyotaro Horiguchi <[email protected]> writes:
> Okay. the points you brought up above are sufficient grounds for not
> doing so. Now they are in the following format.
> LOG: terminating process 16034 to release replication slot "rep1"
> because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
This seems to me to be a pretty blatant violation of our first message
style guideline [1]:
The primary message should be short, factual, and avoid reference to
implementation details such as specific function names. “Short” means
“should fit on one line under normal conditions”. Use a detail message
if needed to keep the primary message short ...
I think you should leave the primary message alone and add a DETAIL,
as the first version of the patch did.
The existing "invalidating slot" message is already in violation
of this guideline, so splitting off a DETAIL from that seems
indicated as well.
regards, tom lane
[1] https://www.postgresql.org/docs/devel/error-style-guide.html
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
@ 2022-09-28 20:38 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 26+ messages in thread
From: Tom Lane @ 2022-09-28 20:38 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
... oh, one other point is that using %ld to print an int64 is entirely
not portable, as indeed the cfbot is complaining about.
I think our best practice on that is to put %lld in the format string
and explicitly cast the corresponding argument to "long long".
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
@ 2022-09-29 05:27 ` Kyotaro Horiguchi <[email protected]>
2022-09-29 17:31 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
1 sibling, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-29 05:27 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
At Wed, 28 Sep 2022 16:30:37 -0400, Tom Lane <[email protected]> wrote in
> Kyotaro Horiguchi <[email protected]> writes:
> > Okay. the points you brought up above are sufficient grounds for not
> > doing so. Now they are in the following format.
>
> > LOG: terminating process 16034 to release replication slot "rep1"
> > because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
>
> This seems to me to be a pretty blatant violation of our first message
> style guideline [1]:
Thanks! It seems that I was waiting for a comment on that line. I
thought that way at first but finally returned to the current message
as the result of discussion (in my memory). I will happily make the
main message shorter.
> I think you should leave the primary message alone and add a DETAIL,
> as the first version of the patch did.
>
> The existing "invalidating slot" message is already in violation
> of this guideline, so splitting off a DETAIL from that seems
> indicated as well.
So I'm going to change the mssage as:
LOG: terminating process %d to release replication slot \"%s\"
DETAIL: The slot's restart_lsn %X/%X exceeds the limit by %lld bytes.
HINT: You might need to increase max_slot_wal_keep_size.
LOG: invalidating *replication* slot \"%s\"
DETAILS: (ditto)
HINTS: (ditto)
It seems that it's no longer useful to split out the first patch so I
merged them into one.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-29 05:27 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-29 17:31 ` Tom Lane <[email protected]>
2022-09-30 02:15 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Tom Lane @ 2022-09-29 17:31 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
Kyotaro Horiguchi <[email protected]> writes:
> At Wed, 28 Sep 2022 16:30:37 -0400, Tom Lane <[email protected]> wrote in
>> I think you should leave the primary message alone and add a DETAIL,
>> as the first version of the patch did.
> So I'm going to change the mssage as:
> LOG: terminating process %d to release replication slot \"%s\"
> DETAIL: The slot's restart_lsn %X/%X exceeds the limit by %lld bytes.
> HINT: You might need to increase max_slot_wal_keep_size.
> LOG: invalidating *replication* slot \"%s\"
> DETAILS: (ditto)
> HINTS: (ditto)
I thought the latter was a little *too* short; the primary message
should at least give you some clue why that happened, even if it
doesn't offer all the detail. After some thought I changed it to
LOG: invalidating obsolete replication slot \"%s\"
and pushed it that way.
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-29 05:27 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-29 17:31 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
@ 2022-09-30 02:15 ` Kyotaro Horiguchi <[email protected]>
2022-09-30 02:49 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-30 02:15 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
At Thu, 29 Sep 2022 13:31:00 -0400, Tom Lane <[email protected]> wrote in
> Kyotaro Horiguchi <[email protected]> writes:
> > At Wed, 28 Sep 2022 16:30:37 -0400, Tom Lane <[email protected]> wrote in
> > LOG: invalidating *replication* slot \"%s\"
> > DETAILS: (ditto)
> > HINTS: (ditto)
>
> I thought the latter was a little *too* short; the primary message
> should at least give you some clue why that happened, even if it
> doesn't offer all the detail. After some thought I changed it to
Yeah, agreed. It looks better. (I was about to spell it as
"invalidating slot "%s"" then changed my mind to add "replication". I
felt that it is a bit too short but didn't think about further
streaching that by adding "obsolete"..).
> LOG: invalidating obsolete replication slot \"%s\"
>
> and pushed it that way.
Thanks. And thanks for fixing the test script, too.
By the way, I didn't notice at that time (and forgot about the
policy), but the HINT message has variations differing only by the
variable name.
What do you think about the attached?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachments:
[text/x-patch] unify_you_migh_need_to_increase_messages.patch (5.8K, ../../[email protected]/2-unify_you_migh_need_to_increase_messages.patch)
download | inline diff:
diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c
index 3bbd522724..2106a8d41d 100644
--- a/src/backend/replication/logical/launcher.c
+++ b/src/backend/replication/logical/launcher.c
@@ -363,7 +363,8 @@ retry:
ereport(WARNING,
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
errmsg("out of logical replication worker slots"),
- errhint("You might need to increase max_logical_replication_workers.")));
+ errhint("You might need to increase %s.",
+ "max_logical_replication_workers")));
return;
}
@@ -420,7 +421,8 @@ retry:
ereport(WARNING,
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
errmsg("out of background worker slots"),
- errhint("You might need to increase max_worker_processes.")));
+ errhint("You might need to increase %s.",
+ "max_worker_processes")));
return;
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index e9328961dd..5ea9b73980 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1298,7 +1298,8 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
errdetail("The slot's restart_lsn %X/%X exceeds the limit by %llu bytes.",
LSN_FORMAT_ARGS(restart_lsn),
(unsigned long long) (oldestLSN - restart_lsn)),
- errhint("You might need to increase max_slot_wal_keep_size."));
+ errhint("You might need to increase %s.",
+ "max_slot_wal_keep_size"));
(void) kill(active_pid, SIGTERM);
last_signaled_pid = active_pid;
@@ -1340,7 +1341,8 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
errdetail("The slot's restart_lsn %X/%X exceeds the limit by %llu bytes.",
LSN_FORMAT_ARGS(restart_lsn),
(unsigned long long) (oldestLSN - restart_lsn)),
- errhint("You might need to increase max_slot_wal_keep_size."));
+ errhint("You might need to increase %s.",
+ "max_slot_wal_keep_size"));
/* done with this slot for now */
break;
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 5f5803f681..5a29f4d346 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -980,7 +980,8 @@ LockAcquireExtended(const LOCKTAG *locktag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_locks_per_transaction")));
else
return LOCKACQUIRE_NOT_AVAIL;
}
@@ -1018,7 +1019,8 @@ LockAcquireExtended(const LOCKTAG *locktag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_locks_per_transaction")));
else
return LOCKACQUIRE_NOT_AVAIL;
}
@@ -2843,7 +2845,8 @@ FastPathGetRelationLockEntry(LOCALLOCK *locallock)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_locks_per_transaction")));
}
GrantLock(proclock->tag.myLock, proclock, lockmode);
FAST_PATH_CLEAR_LOCKMODE(MyProc, f, lockmode);
@@ -4257,7 +4260,8 @@ lock_twophase_recover(TransactionId xid, uint16 info,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_locks_per_transaction")));
}
/*
@@ -4322,7 +4326,8 @@ lock_twophase_recover(TransactionId xid, uint16 info,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_locks_per_transaction")));
}
/*
@@ -4672,7 +4677,8 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_locks_per_transaction")));
}
GrantLock(proclock->tag.myLock, proclock, ExclusiveLock);
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index e8120174d6..6ea1052ba6 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -2471,7 +2471,8 @@ CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_pred_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_pred_locks_per_transaction")));
if (!found)
SHMQueueInit(&(target->predicateLocks));
@@ -2486,7 +2487,8 @@ CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_pred_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_pred_locks_per_transaction")));
if (!found)
{
@@ -3968,7 +3970,8 @@ ReleaseOneSerializableXact(SERIALIZABLEXACT *sxact, bool partial,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
- errhint("You might need to increase max_pred_locks_per_transaction.")));
+ errhint("You might need to increase %s.",
+ "max_pred_locks_per_transaction")));
if (found)
{
Assert(predlock->commitSeqNo != 0);
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-29 05:27 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-29 17:31 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-30 02:15 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2022-09-30 02:49 ` Tom Lane <[email protected]>
2022-09-30 04:49 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 26+ messages in thread
From: Tom Lane @ 2022-09-30 02:49 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
Kyotaro Horiguchi <[email protected]> writes:
> By the way, I didn't notice at that time (and forgot about the
> policy), but the HINT message has variations differing only by the
> variable name.
> What do you think about the attached?
Hmm, maybe, but a quick grep for 'You might need to increase'
finds about a dozen other cases, and none of them are using %s.
If we do this we should change all of them, and they probably
need "translator:" hints. I'm not sure whether abstracting
away the variable names will make translation harder.
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-29 05:27 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-29 17:31 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-30 02:15 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-30 02:49 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
@ 2022-09-30 04:49 ` Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 26+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-30 04:49 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers
At Thu, 29 Sep 2022 22:49:00 -0400, Tom Lane <[email protected]> wrote in
> Kyotaro Horiguchi <[email protected]> writes:
> > By the way, I didn't notice at that time (and forgot about the
> > policy), but the HINT message has variations differing only by the
> > variable name.
>
> > What do you think about the attached?
>
> Hmm, maybe, but a quick grep for 'You might need to increase'
> finds about a dozen other cases, and none of them are using %s.
(Mmm. I didn't find others only in po files..)
> If we do this we should change all of them, and they probably
> need "translator:" hints. I'm not sure whether abstracting
> away the variable names will make translation harder.
I expect that dedicated po-editing tools can lookup corresponding code
lines, which gives the answer if no hint is attached at least in this
specific case.
Anyway, thinking calmly, since we are not about to edit these
messages, it's unlikely to happen on purpose, I think. So I don't mean
to push this so hard.
Thanks for the comment!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: more descriptive message for process termination due to max_slot_wal_keep_size
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
@ 2021-12-14 14:13 ` Bharath Rupireddy <[email protected]>
1 sibling, 0 replies; 26+ messages in thread
From: Bharath Rupireddy @ 2021-12-14 14:13 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: pgsql-hackers
On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
<[email protected]> wrote:
>
> Hello.
>
> As complained in pgsql-bugs [1], when a process is terminated due to
> max_slot_wal_keep_size, the related messages don't mention the root
> cause for *the termination*. Note that the third message does not
> show for temporary replication slots.
>
> [pid=a] LOG: "terminating process %d to release replication slot \"%s\""
> [pid=x] LOG: FATAL: terminating connection due to administrator command
> [pid=a] LOG: invalidting slot "s" because its restart_lsn X/X exceeds max_slot_wal_keep_size
>
> The attached patch attaches a DETAIL line to the first message.
>
> > [17605] LOG: terminating process 17614 to release replication slot "s1"
> + [17605] DETAIL: The slot's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
> > [17614] FATAL: terminating connection due to administrator command
> > [17605] LOG: invalidating slot "s1" because its restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size
>
> Somewhat the second and fourth lines look inconsistent each other but
> that wouldn't be such a problem. I don't think we want to concatenate
> the two lines together as the result is a bit too long.
>
> > LOG: terminating process 17614 to release replication slot "s1" because it's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size.
>
> What do you think about this?
>
> [1] https://www.postgresql.org/message-id/20211214.101137.379073733372253470.horikyota.ntt%40gmail.com
+1 to give more context to the "terminating process %d to release
replication slot \"%s\"" message.
How about having below, instead of adding errdetail:
"terminating process %d to release replication slot \"%s\" whose
restart_lsn %X/%X exceeds max_slot_wal_keep_size"?
I think we can keep the "invalidating slot \"%s\" because its
restart_lsn %X/%X exceeds max_slot_wal_keep_size" message as-is. We
may not see "terminating process ..." and "invalidation slot ..."
messages together for the same slot, so having slightly different
wording is fine IMO.
Regards,
Bharath Rupireddy.
^ permalink raw reply [nested|flat] 26+ messages in thread
end of thread, other threads:[~2022-09-30 04:49 UTC | newest]
Thread overview: 26+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-02-27 04:03 [PATCH 01/10] Allow alternate compression methods for wal_compression Andrey Borodin <[email protected]>
2021-12-14 04:04 more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:01 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-15 04:12 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-23 12:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Ashutosh Bapat <[email protected]>
2021-12-24 04:42 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 08:06 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2021-12-24 08:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-24 11:23 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Masahiko Sawada <[email protected]>
2022-01-04 01:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-03-02 06:37 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-05 09:56 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-06 05:53 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-06 08:54 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-07 02:20 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-07 10:16 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-08 04:40 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-08 09:29 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Drouvot, Bertrand <[email protected]>
2022-09-28 20:30 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-28 20:38 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-29 05:27 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-29 17:31 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-30 02:15 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2022-09-30 02:49 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Tom Lane <[email protected]>
2022-09-30 04:49 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Kyotaro Horiguchi <[email protected]>
2021-12-14 14:13 ` Re: more descriptive message for process termination due to max_slot_wal_keep_size Bharath Rupireddy <[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