add missing errdetail for xlogreader allocation failure error
Hi,
It seems like some of the XLogReaderAllocate failure check errors are
not having errdetail "Failed while allocating a WAL reading
processor." but just the errmsg "out of memory". The "out of memory"
message without the errdetail is too generic and let's add it for
consistency and readability of the message in the server logs.
Here's a tiny patch. Thoughts?
Regards,
Bharath Rupireddy.
Attachments:
v1-0001-add-missing-errdetail-for-xlogreader-allocation-f.patchapplication/octet-stream; name=v1-0001-add-missing-errdetail-for-xlogreader-allocation-f.patchDownload
From 49936acf03c55458cdd52ded8433cb60dbb3250f Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Fri, 19 Nov 2021 03:53:25 +0000
Subject: [PATCH v1] add missing errdetail for xlogreader allocation failure
error
---
src/backend/replication/logical/logical.c | 3 ++-
src/backend/replication/walsender.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index b7d9521576..10cbdea124 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -202,7 +202,8 @@ StartupDecodingContext(List *output_plugin_options,
if (!ctx->reader)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
- errmsg("out of memory")));
+ errmsg("out of memory"),
+ errdetail("Failed while allocating a WAL reading processor.")));
ctx->reorder = ReorderBufferAllocate();
ctx->snapshot_builder =
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 7950afb173..84915ed95b 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -681,7 +681,8 @@ StartReplication(StartReplicationCmd *cmd)
if (!xlogreader)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
- errmsg("out of memory")));
+ errmsg("out of memory"),
+ errdetail("Failed while allocating a WAL reading processor.")));
/*
* We assume here that we're logging enough information in the WAL for
--
2.25.1
On 19 Nov 2021, at 04:59, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
It seems like some of the XLogReaderAllocate failure check errors are
not having errdetail "Failed while allocating a WAL reading
processor." but just the errmsg "out of memory". The "out of memory"
message without the errdetail is too generic and let's add it for
consistency and readability of the message in the server logs.Here's a tiny patch. Thoughts?
No objections. There are quite a few more "out of memory" errors without
errdetail but that doesn't mean we can't move the needle with these.
--
Daniel Gustafsson https://vmware.com/
Le lun. 22 nov. 2021 à 19:58, Daniel Gustafsson <daniel@yesql.se> a écrit :
On 19 Nov 2021, at 04:59, Bharath Rupireddy <
bharath.rupireddyforpostgres@gmail.com> wrote:
It seems like some of the XLogReaderAllocate failure check errors are
not having errdetail "Failed while allocating a WAL reading
processor." but just the errmsg "out of memory". The "out of memory"
message without the errdetail is too generic and let's add it for
consistency and readability of the message in the server logs.Here's a tiny patch. Thoughts?
No objections. There are quite a few more "out of memory" errors without
errdetail but that doesn't mean we can't move the needle with these.
+1, it's often annoying to find out which code path actually raised that
error so this would be quite handy.
Show quoted text
On 2021-Nov-19, Bharath Rupireddy wrote:
It seems like some of the XLogReaderAllocate failure check errors are
not having errdetail "Failed while allocating a WAL reading
processor." but just the errmsg "out of memory". The "out of memory"
message without the errdetail is too generic and let's add it for
consistency and readability of the message in the server logs.Here's a tiny patch. Thoughts?
You're right -- and since in a few other callers of XLogReaderAllocate
we do include the exact errdetail you propose, your patch looks good to
me.
While looking I noticed a few other places that could be improved similarly. I
crammed it all in a single commit, and pushed.
Thank you,
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/