public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 01/10] Allow alternate compression methods for wal_compression
7+ messages / 5 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; 7+ 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 | 52 +++++++++++++--
src/backend/access/transam/xlogreader.c | 63 ++++++++++++++++++-
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 | 8 +++
src/include/access/xlogreader.h | 1 +
src/include/access/xlogrecord.h | 9 +--
11 files changed, 163 insertions(+), 12 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 e04250f4e9..04192b7add 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..34e1227381 100644
--- a/src/backend/access/transam/xloginsert.c
+++ b/src/backend/access/transam/xloginsert.c
@@ -33,6 +33,10 @@
#include "storage/proc.h"
#include "utils/memutils.h"
+#ifdef HAVE_LIBZ
+#include <zlib.h>
+#endif
+
/* Buffer size required to store a compressed version of backup block image */
#define PGLZ_MAX_BLCKSZ PGLZ_MAX_OUTPUT(BLCKSZ)
@@ -113,7 +117,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
@@ -630,11 +635,12 @@ XLogRecordAssemble(RmgrId rmid, uint8 info,
*/
if (wal_compression)
{
+ bimg.compression_method = wal_compression_method;
is_compressed =
XLogCompressBackupBlock(page, bimg.hole_offset,
cbimg.hole_length,
regbuf->compressed_page,
- &compressed_len);
+ &compressed_len, bimg.compression_method);
}
/*
@@ -827,7 +833,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 +859,48 @@ 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 = PGLZ_MAX_BLCKSZ;
+ int ret;
+ ret = compress2((Bytef*)dest, &len_l, (Bytef*)source, orig_len, 1);
+ if (ret != Z_OK)
+ {
+ // XXX: using an interface other than compress() would allow giving a better error message
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("failed compressing zlib (%d)", ret)));
+ 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..afca22a26c 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);
@@ -1286,6 +1290,7 @@ DecodeXLogRecord(XLogReaderState *state, XLogRecord *record, char **errormsg)
{
COPY_HEADER_FIELD(&blk->bimg_len, sizeof(uint16));
COPY_HEADER_FIELD(&blk->hole_offset, sizeof(uint16));
+ COPY_HEADER_FIELD(&blk->compression_method, sizeof(uint8));
COPY_HEADER_FIELD(&blk->bimg_info, sizeof(uint8));
blk->apply_image = ((blk->bimg_info & BKPIMAGE_APPLY) != 0);
@@ -1535,6 +1540,29 @@ XLogRecGetBlockData(XLogReaderState *record, uint8 block_id, Size *len)
}
}
+/*
+ * Return a statically allocated string associated with the given compression
+ * method. This is similar to the guc, but isn't subject to conditional
+ * compilation.
+ */
+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.
+ */
+ switch (compression)
+ {
+ case WAL_COMPRESSION_PGLZ:
+ return "pglz";
+ case WAL_COMPRESSION_ZLIB:
+ return "zlib";
+ default:
+ return "???";
+ }
+}
+
/*
* Restore a full-page image from a backup block attached to an XLOG record.
*
@@ -1558,8 +1586,39 @@ RestoreBlockImage(XLogReaderState *record, uint8 block_id, char *page)
if (bkpb->bimg_info & BKPIMAGE_IS_COMPRESSED)
{
/* 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 (bkpb->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,
+ bkpb->compression_method,
+ wal_compression_name(bkpb->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..d653839b97 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -324,4 +324,12 @@ extern bool InArchiveRecovery;
extern bool StandbyMode;
extern char *recoveryRestoreCommand;
+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/xlogreader.h b/src/include/access/xlogreader.h
index 21d200d3df..3d19c315d7 100644
--- a/src/include/access/xlogreader.h
+++ b/src/include/access/xlogreader.h
@@ -133,6 +133,7 @@ typedef struct
bool apply_image; /* has image that should be restored */
char *bkp_image;
uint16 hole_offset;
+ uint8 compression_method;
uint16 hole_length;
uint16 bimg_len;
uint8 bimg_info;
diff --git a/src/include/access/xlogrecord.h b/src/include/access/xlogrecord.h
index 80c92a2498..0d4c212f15 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
@@ -129,9 +129,10 @@ typedef struct XLogRecordBlockHeader
*/
typedef struct XLogRecordBlockImageHeader
{
- uint16 length; /* number of page image bytes */
- uint16 hole_offset; /* number of bytes before "hole" */
- uint8 bimg_info; /* flag bits, see below */
+ uint16 length; /* number of page image bytes */
+ uint16 hole_offset; /* number of bytes before "hole" */
+ uint8 compression_method; /* compression method used for image */
+ uint8 bimg_info; /* flag bits, see below */
/*
* If BKPIMAGE_HAS_HOLE and BKPIMAGE_IS_COMPRESSED, an
--
2.17.0
--0qVF/w3MHQqLSynd
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] 7+ messages in thread
* Re: Memory leak in incremental sort re-scan
@ 2023-06-15 20:36 Tom Lane <[email protected]>
2023-06-15 22:34 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Tom Lane @ 2023-06-15 20:36 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]
Tomas Vondra <[email protected]> writes:
> On 6/15/23 22:11, Tom Lane wrote:
>> I see zero leakage in that example after applying the attached quick
>> hack. (It might be better to make the check in the caller, or to just
>> move the call to ExecInitIncrementalSort.)
> Thanks for looking. Are you planning to work on this and push the fix,
> or do you want me to finish this up?
I'm happy to let you take it -- got lots of other stuff on my plate.
regards, tom lane
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Memory leak in incremental sort re-scan
2023-06-15 20:36 Re: Memory leak in incremental sort re-scan Tom Lane <[email protected]>
@ 2023-06-15 22:34 ` Tomas Vondra <[email protected]>
2023-06-21 18:54 ` Re: Memory leak in incremental sort re-scan James Coleman <[email protected]>
2023-06-29 11:49 ` Re: Memory leak in incremental sort re-scan Laurenz Albe <[email protected]>
0 siblings, 2 replies; 7+ messages in thread
From: Tomas Vondra @ 2023-06-15 22:34 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]
On 6/15/23 22:36, Tom Lane wrote:
> Tomas Vondra <[email protected]> writes:
>> On 6/15/23 22:11, Tom Lane wrote:
>>> I see zero leakage in that example after applying the attached quick
>>> hack. (It might be better to make the check in the caller, or to just
>>> move the call to ExecInitIncrementalSort.)
>
>> Thanks for looking. Are you planning to work on this and push the fix,
>> or do you want me to finish this up?
>
> I'm happy to let you take it -- got lots of other stuff on my plate.
>
OK, will do.
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Memory leak in incremental sort re-scan
2023-06-15 20:36 Re: Memory leak in incremental sort re-scan Tom Lane <[email protected]>
2023-06-15 22:34 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
@ 2023-06-21 18:54 ` James Coleman <[email protected]>
1 sibling, 0 replies; 7+ messages in thread
From: James Coleman @ 2023-06-21 18:54 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; +Cc: Tom Lane <[email protected]>; Laurenz Albe <[email protected]>; [email protected]
On Thu, Jun 15, 2023 at 6:35 PM Tomas Vondra
<[email protected]> wrote:
>
>
>
> On 6/15/23 22:36, Tom Lane wrote:
> > Tomas Vondra <[email protected]> writes:
> >> On 6/15/23 22:11, Tom Lane wrote:
> >>> I see zero leakage in that example after applying the attached quick
> >>> hack. (It might be better to make the check in the caller, or to just
> >>> move the call to ExecInitIncrementalSort.)
> >
> >> Thanks for looking. Are you planning to work on this and push the fix,
> >> or do you want me to finish this up?
> >
> > I'm happy to let you take it -- got lots of other stuff on my plate.
> >
>
> OK, will do.
I think the attached is enough to fix it -- rather than nulling out
the sort states in rescan, we can reset them (as the comment says),
but not set them to null (we also have the same mistake with
presorted_keys). That avoids unnecessary recreation of the sort
states, but it also fixes the problem Tom noted as well: the call to
preparePresortedCols() is already guarded by a test on fullsort_state
being NULL, so with this change we also won't unnecessarily redo that
work.
Regards,
James Coleman
Attachments:
[application/octet-stream] v2-0001-Fix-memory-leak-in-incremental-sort-rescan.patch (1.6K, ../../CAAaqYe-iFFT0FeqEfhjYQHSHYSrc_kfPpcYfSB1kgOGq8M2tfQ@mail.gmail.com/2-v2-0001-Fix-memory-leak-in-incremental-sort-rescan.patch)
download | inline diff:
From e5848bc3f9de7becc2a5273ff0e0d4685f7905fa Mon Sep 17 00:00:00 2001
From: jcoleman <[email protected]>
Date: Wed, 21 Jun 2023 14:31:44 -0400
Subject: [PATCH v2] Fix memory leak in incremental sort rescan
There are multiple issues here that this solves:
1. The sort states are incorrectly set to NULL during a rescan (despite
the comment saying otherwise), and so we never end them.
2. presorted_keys is also incorrectly set to NULL during a rescan.
2. Because fullsort_state is improperly NULL we additionally call
preparePresortedCols more than once, leaking memory there as well.
---
src/backend/executor/nodeIncrementalSort.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c
index 34257ce34b..7683e3341c 100644
--- a/src/backend/executor/nodeIncrementalSort.c
+++ b/src/backend/executor/nodeIncrementalSort.c
@@ -1140,7 +1140,6 @@ ExecReScanIncrementalSort(IncrementalSortState *node)
node->outerNodeDone = false;
node->n_fullsort_remaining = 0;
node->bound_Done = 0;
- node->presorted_keys = NULL;
node->execution_status = INCSORT_LOADFULLSORT;
@@ -1153,15 +1152,9 @@ ExecReScanIncrementalSort(IncrementalSortState *node)
* cause a leak.
*/
if (node->fullsort_state != NULL)
- {
tuplesort_reset(node->fullsort_state);
- node->fullsort_state = NULL;
- }
if (node->prefixsort_state != NULL)
- {
tuplesort_reset(node->prefixsort_state);
- node->prefixsort_state = NULL;
- }
/*
* If chgParam of subnode is not null, then the plan will be re-scanned by
--
2.39.2 (Apple Git-143)
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Memory leak in incremental sort re-scan
2023-06-15 20:36 Re: Memory leak in incremental sort re-scan Tom Lane <[email protected]>
2023-06-15 22:34 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
@ 2023-06-29 11:49 ` Laurenz Albe <[email protected]>
2023-07-02 18:13 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
1 sibling, 1 reply; 7+ messages in thread
From: Laurenz Albe @ 2023-06-29 11:49 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; Tom Lane <[email protected]>; +Cc: [email protected]
On Fri, 2023-06-16 at 00:34 +0200, Tomas Vondra wrote:
> On 6/15/23 22:36, Tom Lane wrote:
> > Tomas Vondra <[email protected]> writes:
> > > On 6/15/23 22:11, Tom Lane wrote:
> > > > I see zero leakage in that example after applying the attached quick
> > > > hack. (It might be better to make the check in the caller, or to just
> > > > move the call to ExecInitIncrementalSort.)
> >
> > > Thanks for looking. Are you planning to work on this and push the fix,
> > > or do you want me to finish this up?
> >
> > I'm happy to let you take it -- got lots of other stuff on my plate.
>
> OK, will do.
It would be cool if we could get that into the next minor release in August.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Memory leak in incremental sort re-scan
2023-06-15 20:36 Re: Memory leak in incremental sort re-scan Tom Lane <[email protected]>
2023-06-15 22:34 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
2023-06-29 11:49 ` Re: Memory leak in incremental sort re-scan Laurenz Albe <[email protected]>
@ 2023-07-02 18:13 ` Tomas Vondra <[email protected]>
2023-07-02 19:52 ` Re: Memory leak in incremental sort re-scan Laurenz Albe <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Tomas Vondra @ 2023-07-02 18:13 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; Tom Lane <[email protected]>; +Cc: [email protected]
On 6/29/23 13:49, Laurenz Albe wrote:
> On Fri, 2023-06-16 at 00:34 +0200, Tomas Vondra wrote:
>> On 6/15/23 22:36, Tom Lane wrote:
>>> Tomas Vondra <[email protected]> writes:
>>>> On 6/15/23 22:11, Tom Lane wrote:
>>>>> I see zero leakage in that example after applying the attached quick
>>>>> hack. (It might be better to make the check in the caller, or to just
>>>>> move the call to ExecInitIncrementalSort.)
>>>
>>>> Thanks for looking. Are you planning to work on this and push the fix,
>>>> or do you want me to finish this up?
>>>
>>> I'm happy to let you take it -- got lots of other stuff on my plate.
>>
>> OK, will do.
>
> It would be cool if we could get that into the next minor release in August.
>
FWIW I've pushed the fix prepared by James a couple days ago. Thanks for
the report!
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Memory leak in incremental sort re-scan
2023-06-15 20:36 Re: Memory leak in incremental sort re-scan Tom Lane <[email protected]>
2023-06-15 22:34 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
2023-06-29 11:49 ` Re: Memory leak in incremental sort re-scan Laurenz Albe <[email protected]>
2023-07-02 18:13 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
@ 2023-07-02 19:52 ` Laurenz Albe <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Laurenz Albe @ 2023-07-02 19:52 UTC (permalink / raw)
To: Tomas Vondra <[email protected]>; Tom Lane <[email protected]>; +Cc: [email protected]
On Sun, 2023-07-02 at 20:13 +0200, Tomas Vondra wrote:
> FWIW I've pushed the fix prepared by James a couple days ago. Thanks for
> the report!
Thanks, and sorry for being pushy.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2023-07-02 19:52 UTC | newest]
Thread overview: 7+ 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]>
2023-06-15 20:36 Re: Memory leak in incremental sort re-scan Tom Lane <[email protected]>
2023-06-15 22:34 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
2023-06-21 18:54 ` Re: Memory leak in incremental sort re-scan James Coleman <[email protected]>
2023-06-29 11:49 ` Re: Memory leak in incremental sort re-scan Laurenz Albe <[email protected]>
2023-07-02 18:13 ` Re: Memory leak in incremental sort re-scan Tomas Vondra <[email protected]>
2023-07-02 19:52 ` Re: Memory leak in incremental sort re-scan Laurenz Albe <[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