public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v15 1/4] Prevent jumbling of every element in ArrayExpr
7+ messages / 4 participants
[nested] [flat]
* [PATCH v15 1/4] Prevent jumbling of every element in ArrayExpr
@ 2023-10-14 13:00 Dmitrii Dolgov <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Dmitrii Dolgov @ 2023-10-14 13:00 UTC (permalink / raw)
pg_stat_statements produces multiple entries for queries like
SELECT something FROM table WHERE col IN (1, 2, 3, ...)
depending on the number of parameters, because every element of
ArrayExpr is jumbled. In certain situations it's undesirable, especially
if the list becomes too large.
Make an array of Const expressions contribute only the first/last
elements to the jumble hash. Allow to enable this behavior via the new
GUC query_id_const_merge with the default value off.
Reviewed-by: Zhihong Yu, Sergey Dudoladov, Robert Haas, Tom Lane,
Michael Paquier, Sergei Kornilov, Alvaro Herrera, David Geier
Tested-by: Chengxi Sun
---
contrib/pg_stat_statements/Makefile | 2 +-
.../pg_stat_statements/expected/merging.out | 167 ++++++++++++++++++
contrib/pg_stat_statements/meson.build | 1 +
.../pg_stat_statements/pg_stat_statements.c | 34 +++-
contrib/pg_stat_statements/sql/merging.sql | 58 ++++++
doc/src/sgml/config.sgml | 28 +++
doc/src/sgml/pgstatstatements.sgml | 25 ++-
src/backend/nodes/gen_node_support.pl | 2 +-
src/backend/nodes/queryjumblefuncs.c | 86 ++++++++-
src/backend/utils/misc/guc_tables.c | 10 ++
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/include/nodes/primnodes.h | 2 +
src/include/nodes/queryjumble.h | 9 +-
13 files changed, 406 insertions(+), 20 deletions(-)
create mode 100644 contrib/pg_stat_statements/expected/merging.out
create mode 100644 contrib/pg_stat_statements/sql/merging.sql
diff --git a/contrib/pg_stat_statements/Makefile b/contrib/pg_stat_statements/Makefile
index eba4a95d91a..af731fc9a58 100644
--- a/contrib/pg_stat_statements/Makefile
+++ b/contrib/pg_stat_statements/Makefile
@@ -19,7 +19,7 @@ LDFLAGS_SL += $(filter -lm, $(LIBS))
REGRESS_OPTS = --temp-config $(top_srcdir)/contrib/pg_stat_statements/pg_stat_statements.conf
REGRESS = select dml cursors utility level_tracking planning \
- user_activity wal cleanup oldextversions
+ user_activity wal cleanup oldextversions merging
# Disabled because these tests require "shared_preload_libraries=pg_stat_statements",
# which typical installcheck users do not have (e.g. buildfarm clients).
NO_INSTALLCHECK = 1
diff --git a/contrib/pg_stat_statements/expected/merging.out b/contrib/pg_stat_statements/expected/merging.out
new file mode 100644
index 00000000000..7711572e0b7
--- /dev/null
+++ b/contrib/pg_stat_statements/expected/merging.out
@@ -0,0 +1,167 @@
+--
+-- Const merging functionality
+--
+CREATE EXTENSION pg_stat_statements;
+CREATE TABLE test_merge (id int, data int);
+-- IN queries
+-- No merging is performed, as a baseline result
+SELECT pg_stat_statements_reset();
+ pg_stat_statements_reset
+--------------------------
+
+(1 row)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9);
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+ id | data
+----+------
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query | calls
+-------------------------------------------------------------------------------------+-------
+ SELECT * FROM test_merge WHERE id IN ($1, $2, $3, $4, $5, $6, $7, $8, $9) | 1
+ SELECT * FROM test_merge WHERE id IN ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10) | 1
+ SELECT * FROM test_merge WHERE id IN ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11) | 1
+ SELECT pg_stat_statements_reset() | 1
+(4 rows)
+
+-- Normal scenario, too many simple constants for an IN query
+SET query_id_const_merge = on;
+SELECT pg_stat_statements_reset();
+ pg_stat_statements_reset
+--------------------------
+
+(1 row)
+
+SELECT * FROM test_merge WHERE id IN (1);
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3);
+ id | data
+----+------
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query | calls
+--------------------------------------------+-------
+ SELECT * FROM test_merge WHERE id IN ($1) | 1
+ SELECT * FROM test_merge WHERE id IN (...) | 1
+ SELECT pg_stat_statements_reset() | 1
+(3 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9);
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+ id | data
+----+------
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query | calls
+------------------------------------------------------------------------+-------
+ SELECT * FROM test_merge WHERE id IN ($1) | 1
+ SELECT * FROM test_merge WHERE id IN (...) | 4
+ SELECT pg_stat_statements_reset() | 1
+ SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C" | 1
+(4 rows)
+
+-- More conditions in the query
+SELECT pg_stat_statements_reset();
+ pg_stat_statements_reset
+--------------------------
+
+(1 row)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9) and data = 2;
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and data = 2;
+ id | data
+----+------
+(0 rows)
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) and data = 2;
+ id | data
+----+------
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query | calls
+----------------------------------------------------------+-------
+ SELECT * FROM test_merge WHERE id IN (...) and data = $3 | 3
+ SELECT pg_stat_statements_reset() | 1
+(2 rows)
+
+-- No constants simplification
+SELECT pg_stat_statements_reset();
+ pg_stat_statements_reset
+--------------------------
+
+(1 row)
+
+SELECT * FROM test_merge WHERE id IN (1 + 1, 2 + 2, 3 + 3, 4 + 4, 5 + 5, 6 + 6, 7 + 7, 8 + 8, 9 + 9);
+ id | data
+----+------
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query | calls
+---------------------------------------------------------------------------------------------------------------------------------+-------
+ SELECT * FROM test_merge WHERE id IN ($1 + $2, $3 + $4, $5 + $6, $7 + $8, $9 + $10, $11 + $12, $13 + $14, $15 + $16, $17 + $18) | 1
+ SELECT pg_stat_statements_reset() | 1
+(2 rows)
+
+-- Numeric type
+CREATE TABLE test_merge_numeric (id int, data numeric(5, 2));
+SELECT pg_stat_statements_reset();
+ pg_stat_statements_reset
+--------------------------
+
+(1 row)
+
+SELECT * FROM test_merge_numeric WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+ id | data
+----+------
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query | calls
+----------------------------------------------------+-------
+ SELECT * FROM test_merge_numeric WHERE id IN (...) | 1
+ SELECT pg_stat_statements_reset() | 1
+(2 rows)
+
+-- Test constants evaluation, verifies a tricky part to make sure there are no
+-- issues in the merging implementation
+WITH cte AS (
+ SELECT 'const' as const FROM test_merge
+)
+SELECT ARRAY['a', 'b', 'c', const::varchar] AS result
+FROM cte;
+ result
+--------
+(0 rows)
+
+RESET query_id_const_merge;
diff --git a/contrib/pg_stat_statements/meson.build b/contrib/pg_stat_statements/meson.build
index 15b7c7f2b02..6371c81e138 100644
--- a/contrib/pg_stat_statements/meson.build
+++ b/contrib/pg_stat_statements/meson.build
@@ -51,6 +51,7 @@ tests += {
'wal',
'cleanup',
'oldextversions',
+ 'merging',
],
'regress_args': ['--temp-config', files('pg_stat_statements.conf')],
# Disabled because these tests require
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index a46f2db352b..0b03009a053 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -2695,6 +2695,9 @@ generate_normalized_query(JumbleState *jstate, const char *query,
n_quer_loc = 0, /* Normalized query byte location */
last_off = 0, /* Offset from start for previous tok */
last_tok_len = 0; /* Length (in bytes) of that tok */
+ bool skip = false; /* Signals that certain constants are
+ merged together and have to be skipped */
+
/*
* Get constants' lengths (core system only gives us locations). Note
@@ -2718,7 +2721,6 @@ generate_normalized_query(JumbleState *jstate, const char *query,
{
int off, /* Offset from start for cur tok */
tok_len; /* Length (in bytes) of that tok */
-
off = jstate->clocations[i].location;
/* Adjust recorded location if we're dealing with partial string */
off -= query_loc;
@@ -2733,12 +2735,32 @@ generate_normalized_query(JumbleState *jstate, const char *query,
len_to_wrt -= last_tok_len;
Assert(len_to_wrt >= 0);
- memcpy(norm_query + n_quer_loc, query + quer_loc, len_to_wrt);
- n_quer_loc += len_to_wrt;
- /* And insert a param symbol in place of the constant token */
- n_quer_loc += sprintf(norm_query + n_quer_loc, "$%d",
- i + 1 + jstate->highest_extern_param_id);
+ /* Normal path, non merged constant */
+ if (!jstate->clocations[i].merged)
+ {
+ memcpy(norm_query + n_quer_loc, query + quer_loc, len_to_wrt);
+ n_quer_loc += len_to_wrt;
+
+ /* And insert a param symbol in place of the constant token */
+ n_quer_loc += sprintf(norm_query + n_quer_loc, "$%d",
+ i + 1 + jstate->highest_extern_param_id);
+
+ /* In case previous constants were merged away, stop doing that */
+ if (skip)
+ skip = false;
+ }
+ /* The firsts merged constant */
+ else if (!skip)
+ {
+ memcpy(norm_query + n_quer_loc, query + quer_loc, len_to_wrt);
+ n_quer_loc += len_to_wrt;
+
+ /* Skip the following until a non merged constant appear */
+ skip = true;
+ n_quer_loc += sprintf(norm_query + n_quer_loc, "...");
+ }
+ /* Otherwise the constant is merged away */
quer_loc = off + tok_len;
last_off = off;
diff --git a/contrib/pg_stat_statements/sql/merging.sql b/contrib/pg_stat_statements/sql/merging.sql
new file mode 100644
index 00000000000..02266a92ce8
--- /dev/null
+++ b/contrib/pg_stat_statements/sql/merging.sql
@@ -0,0 +1,58 @@
+--
+-- Const merging functionality
+--
+CREATE EXTENSION pg_stat_statements;
+
+CREATE TABLE test_merge (id int, data int);
+
+-- IN queries
+
+-- No merging is performed, as a baseline result
+SELECT pg_stat_statements_reset();
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9);
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+
+-- Normal scenario, too many simple constants for an IN query
+SET query_id_const_merge = on;
+
+SELECT pg_stat_statements_reset();
+SELECT * FROM test_merge WHERE id IN (1);
+SELECT * FROM test_merge WHERE id IN (1, 2, 3);
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9);
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+
+-- More conditions in the query
+SELECT pg_stat_statements_reset();
+
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9) and data = 2;
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and data = 2;
+SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) and data = 2;
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+
+-- No constants simplification
+SELECT pg_stat_statements_reset();
+
+SELECT * FROM test_merge WHERE id IN (1 + 1, 2 + 2, 3 + 3, 4 + 4, 5 + 5, 6 + 6, 7 + 7, 8 + 8, 9 + 9);
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+
+-- Numeric type
+CREATE TABLE test_merge_numeric (id int, data numeric(5, 2));
+SELECT pg_stat_statements_reset();
+SELECT * FROM test_merge_numeric WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+
+-- Test constants evaluation, verifies a tricky part to make sure there are no
+-- issues in the merging implementation
+WITH cte AS (
+ SELECT 'const' as const FROM test_merge
+)
+SELECT ARRAY['a', 'b', 'c', const::varchar] AS result
+FROM cte;
+
+RESET query_id_const_merge;
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 3839c72c868..55b0795bce1 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -8190,6 +8190,34 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</listitem>
</varlistentry>
+ <varlistentry id="guc-query-id-const-merge" xreflabel="query_id_const_merge">
+ <term><varname>query_id_const_merge</varname> (<type>bool</type>)
+ <indexterm>
+ <primary><varname>query_id_const_merge</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specifies how an array of constants (e.g. for an "IN" clause)
+ contributes to the query identifier computation. Normally every element
+ of an array contributes to the query identifier, which means the same
+ query will get multiple different identifiers, one for each occurrence
+ with an array of different lenght.
+
+ If this parameter is on, an array of constants will contribute only the
+ first and the last elements to the query identifier. It means two
+ occurences of the same query, where the only difference is number of
+ constants in the array, are going to get the same query identifier.
+
+ The parameter could be used to reduce amount of repeating data stored
+ via <xref linkend="pgstatstatements"/> extension. The default value is off.
+
+ The <xref linkend="pgstatstatements"/> extension will represent such
+ queries in form <literal>'(...)'</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</sect2>
diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml
index 7e7c5c9ff82..8df4064cbf4 100644
--- a/doc/src/sgml/pgstatstatements.sgml
+++ b/doc/src/sgml/pgstatstatements.sgml
@@ -548,10 +548,27 @@
<para>
In some cases, queries with visibly different texts might get merged into a
single <structname>pg_stat_statements</structname> entry. Normally this will happen
- only for semantically equivalent queries, but there is a small chance of
- hash collisions causing unrelated queries to be merged into one entry.
- (This cannot happen for queries belonging to different users or databases,
- however.)
+ only for semantically equivalent queries, or if
+ <xref linkend="guc-query-id-const-merge"/> is enabled and the only
+ difference between queries is the length of an array with constants they contain:
+
+<screen>
+=# SET query_id_const_merge = on;
+=# SELECT pg_stat_statements_reset();
+=# SELECT * FROM test WHERE a IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
+=# SELECT * FROM test WHERE a IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);
+=# SELECT query, calls FROM pg_stat_statements;
+-[ RECORD 1 ]------------------------------
+query | SELECT * FROM test WHERE a IN (...)
+calls | 2
+-[ RECORD 2 ]------------------------------
+query | SELECT pg_stat_statements_reset()
+calls | 1
+</screen>
+
+ But there is a small chance of hash collisions causing unrelated queries to
+ be merged into one entry. (This cannot happen for queries belonging to
+ different users or databases, however.)
</para>
<para>
diff --git a/src/backend/nodes/gen_node_support.pl b/src/backend/nodes/gen_node_support.pl
index 72c79635781..5b4a3f37a2b 100644
--- a/src/backend/nodes/gen_node_support.pl
+++ b/src/backend/nodes/gen_node_support.pl
@@ -1308,7 +1308,7 @@ _jumble${n}(JumbleState *jstate, Node *node)
# Track the node's location only if directly requested.
if ($query_jumble_location)
{
- print $jff "\tJUMBLE_LOCATION($f);\n"
+ print $jff "\tJUMBLE_LOCATION($f, false);\n"
unless $query_jumble_ignore;
}
}
diff --git a/src/backend/nodes/queryjumblefuncs.c b/src/backend/nodes/queryjumblefuncs.c
index 281907a4d83..52d45c2b093 100644
--- a/src/backend/nodes/queryjumblefuncs.c
+++ b/src/backend/nodes/queryjumblefuncs.c
@@ -42,12 +42,16 @@
/* GUC parameters */
int compute_query_id = COMPUTE_QUERY_ID_AUTO;
+/* Whether to merge constants in a list when computing query_id */
+bool query_id_const_merge = false;
+
/* True when compute_query_id is ON, or AUTO and a module requests them */
bool query_id_enabled = false;
static void AppendJumble(JumbleState *jstate,
const unsigned char *item, Size size);
-static void RecordConstLocation(JumbleState *jstate, int location);
+static void RecordConstLocation(JumbleState *jstate,
+ int location, bool merged);
static void _jumbleNode(JumbleState *jstate, Node *node);
static void _jumbleA_Const(JumbleState *jstate, Node *node);
static void _jumbleList(JumbleState *jstate, Node *node);
@@ -186,11 +190,15 @@ AppendJumble(JumbleState *jstate, const unsigned char *item, Size size)
}
/*
- * Record location of constant within query string of query tree
- * that is currently being walked.
+ * Record location of constant within query string of query tree that is
+ * currently being walked.
+ *
+ * Merged argument signals that the constant represents the first or the last
+ * element in a series of merged constants, and everything but the first/last
+ * element contributes nothing to the jumble hash.
*/
static void
-RecordConstLocation(JumbleState *jstate, int location)
+RecordConstLocation(JumbleState *jstate, int location, bool merged)
{
/* -1 indicates unknown or undefined location */
if (location >= 0)
@@ -206,15 +214,65 @@ RecordConstLocation(JumbleState *jstate, int location)
}
jstate->clocations[jstate->clocations_count].location = location;
/* initialize lengths to -1 to simplify third-party module usage */
+ jstate->clocations[jstate->clocations_count].merged = merged;
jstate->clocations[jstate->clocations_count].length = -1;
jstate->clocations_count++;
}
}
+/*
+ * Verify if the provided list contains could be merged down, which means it
+ * contains only constant expressions.
+ *
+ * Return value indicates if merging is possible.
+ *
+ * Note that this function searches only for explicit Const nodes and does not
+ * try to simplify expressions.
+ */
+static bool
+IsMergeableConstList(List *elements, Const **firstConst, Const **lastConst)
+{
+ ListCell *temp;
+ Node *firstExpr = NULL;
+
+ if (elements == NULL)
+ return false;
+
+ if (!query_id_const_merge)
+ {
+ /* Merging is disabled, process everything one by one */
+ return false;
+ }
+
+ firstExpr = linitial(elements);
+
+ /*
+ * If the first expression is a constant, verify if the following elements
+ * are constants as well. If yes, the list is eligible for merging, and the
+ * order of magnitude need to be calculated.
+ */
+ if (IsA(firstExpr, Const))
+ {
+ foreach(temp, elements)
+ if (!IsA(lfirst(temp), Const))
+ return false;
+
+ *firstConst = (Const *) firstExpr;
+ *lastConst = llast_node(Const, elements);
+ return true;
+ }
+
+ /*
+ * If we end up here, it means no constants merging is possible, process
+ * the list as usual.
+ */
+ return false;
+}
+
#define JUMBLE_NODE(item) \
_jumbleNode(jstate, (Node *) expr->item)
-#define JUMBLE_LOCATION(location) \
- RecordConstLocation(jstate, expr->location)
+#define JUMBLE_LOCATION(location, merged) \
+ RecordConstLocation(jstate, expr->location, merged)
#define JUMBLE_FIELD(item) \
AppendJumble(jstate, (const unsigned char *) &(expr->item), sizeof(expr->item))
#define JUMBLE_FIELD_SINGLE(item) \
@@ -227,6 +285,22 @@ do { \
#include "queryjumblefuncs.funcs.c"
+static void
+_jumbleArrayExpr(JumbleState *jstate, Node *node)
+{
+ ArrayExpr *expr = (ArrayExpr *) node;
+ Const *first, *last;
+ if(IsMergeableConstList(expr->elements, &first, &last))
+ {
+ RecordConstLocation(jstate, first->location, true);
+ RecordConstLocation(jstate, last->location, true);
+ }
+ else
+ {
+ JUMBLE_NODE(elements);
+ }
+}
+
static void
_jumbleNode(JumbleState *jstate, Node *node)
{
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 4c585741661..fbb50adb9f9 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -2011,6 +2011,16 @@ struct config_bool ConfigureNamesBool[] =
NULL, NULL, NULL
},
+ {
+ {"query_id_const_merge", PGC_SUSET, STATS_MONITORING,
+ gettext_noop("Sets whether an array of constants will contribute to"
+ " query identified computation."),
+ },
+ &query_id_const_merge,
+ false,
+ NULL, NULL, NULL
+ },
+
/* End-of-list marker */
{
{NULL, 0, 0, NULL, NULL}, NULL, false, NULL, NULL, NULL
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index d08d55c3fe4..3397780dc72 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -628,7 +628,7 @@
#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
-
+#query_id_const_merge = off
#------------------------------------------------------------------------------
# AUTOVACUUM
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index 60d72a876b4..fde0320b263 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -1296,6 +1296,8 @@ typedef struct CaseTestExpr
*/
typedef struct ArrayExpr
{
+ pg_node_attr(custom_query_jumble)
+
Expr xpr;
/* type of expression result */
Oid array_typeid pg_node_attr(query_jumble_ignore);
diff --git a/src/include/nodes/queryjumble.h b/src/include/nodes/queryjumble.h
index 7649e095aa5..225957d7b3c 100644
--- a/src/include/nodes/queryjumble.h
+++ b/src/include/nodes/queryjumble.h
@@ -15,6 +15,7 @@
#define QUERYJUMBLE_H
#include "nodes/parsenodes.h"
+#include "nodes/nodeFuncs.h"
/*
* Struct for tracking locations/lengths of constants during normalization
@@ -23,6 +24,12 @@ typedef struct LocationLen
{
int location; /* start offset in query text */
int length; /* length in bytes, or -1 to ignore */
+
+ /*
+ * Indicates the constant represents the beginning or the end of a merged
+ * constants interval.
+ */
+ bool merged;
} LocationLen;
/*
@@ -61,7 +68,7 @@ enum ComputeQueryIdType
/* GUC parameters */
extern PGDLLIMPORT int compute_query_id;
-
+extern PGDLLIMPORT bool query_id_const_merge;
extern const char *CleanQuerytext(const char *query, int *location, int *len);
extern JumbleState *JumbleQuery(Query *query);
base-commit: 22655aa23132a0645fdcdce4b233a1fff0c0cf8f
--
2.41.0
--svnhsmawrtczycxj
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v15-0002-Reusable-decimalLength-functions.patch"
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Fwd: pg18 bug? SELECT query doesn't work
@ 2026-01-08 04:03 Tom Lane <[email protected]>
2026-01-08 13:30 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Tom Lane @ 2026-01-08 04:03 UTC (permalink / raw)
To: Richard Guo <[email protected]>; +Cc: Eric Ridge <[email protected]>; Pg Hackers <[email protected]>
Richard Guo <[email protected]> writes:
> The underlying expression of a join alias Var can only be a Var
> (potentially coerced) from one of the join's input rels, or a COALESCE
> expression containing the two input Vars. Therefore, it should not be
> able to contain SRFs or volatile functions, and thus we do not need to
> expand it beforehand.
[ itch... ] That statement is false in general, because subquery
pullup within the subquery can replace a sub-subquery's output Vars
with expressions. It might be okay for this purpose, as I think we'd
not pull up if the sub-subquery's output expressions are volatile or
SRFs. These assumptions had better be well commented though.
The larger point here is that this behavior is all recursive,
and we can happily end with an expression that's been pulled up
several levels; we'd better make sure the right checks happen.
So I'm a little bit distressed that planner.c's invocations of
flatten_group_exprs are not at all analogous to its usage of
flatten_join_alias_vars. The latter pattern has a couple of
decades of usage to lend credence to the assumption that it's
correct. flatten_group_exprs, um, not so much. It may be
fine, given the fact that grouping Vars can appear within
much less of the query than join aliases. But in view of the
present bug, I'm feeling nervous.
regards, tom lane
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Fwd: pg18 bug? SELECT query doesn't work
2026-01-08 04:03 Re: Fwd: pg18 bug? SELECT query doesn't work Tom Lane <[email protected]>
@ 2026-01-08 13:30 ` Richard Guo <[email protected]>
2026-01-09 09:52 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Richard Guo @ 2026-01-08 13:30 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Eric Ridge <[email protected]>; Pg Hackers <[email protected]>
On Thu, Jan 8, 2026 at 1:03 PM Tom Lane <[email protected]> wrote:
> [ itch... ] That statement is false in general, because subquery
> pullup within the subquery can replace a sub-subquery's output Vars
> with expressions. It might be okay for this purpose, as I think we'd
> not pull up if the sub-subquery's output expressions are volatile or
> SRFs. These assumptions had better be well commented though.
Ah, I see. Once the sub-subqueries are flattened, the join alias
entries in the subquery can become arbitrary expressions rather than
simple Vars. I suspect we have only avoided issues with join aliases
in subquery_is_pushdown_safe() for all these years by sheer luck:
since we don't pull up subqueries that output set-returning or
volatile functions, those 'arbitrary expressions' are unlikely to
include them.
How about we add a comment to check_output_expressions() along the
below lines?
/*
* We need to expand grouping Vars to their underlying expressions (the
* grouping clauses) because the grouping expressions themselves might be
* volatile or set-returning. However, we do not need to recurse deeper
* into the arguments of those expressions. If an argument references a
* lower-level subquery output, we can rely on the fact that subqueries
* containing volatile or set-returning functions in their targetlists are
* never pulled up.
*
* We do not need to expand join alias Vars. The underlying expression of
* a join alias Var does not itself introduce volatility or set-returning
* behavior. As with grouping Vars, we rely on the pull-up restrictions to
* guarantee that any referenced inputs from lower levels are free of such
* functions.
*/
> The larger point here is that this behavior is all recursive,
> and we can happily end with an expression that's been pulled up
> several levels; we'd better make sure the right checks happen.
> So I'm a little bit distressed that planner.c's invocations of
> flatten_group_exprs are not at all analogous to its usage of
> flatten_join_alias_vars. The latter pattern has a couple of
> decades of usage to lend credence to the assumption that it's
> correct. flatten_group_exprs, um, not so much. It may be
> fine, given the fact that grouping Vars can appear within
> much less of the query than join aliases. But in view of the
> present bug, I'm feeling nervous.
I checked the invocations of flatten_join_alias_vars and
flatten_group_exprs in the planner to understand why they are not
being used analogously.
1. planner.c:1041
Here, we call flatten_join_alias_vars on the subquery because the
subquery may contain join aliases from the outer query level; since
these won't be expanded during the subquery's own planning, we must
expand them now. A query illustrating this scenario is:
select * from tenk1 t1 full join tenk1 t2 using (unique1)
join lateral (select unique1 offset 0) on true;
(BTW, the test cases added in da3df9987 for this logic are no longer
valid. These queries still function correctly even if this code is
removed. I think this is something we should fix.)
However, I don't think an analogous call to flatten_group_exprs is
necessary here. Subqueries should not contain grouping-Vars from the
outer query, since FROM clause is processed before the GROUP BY step.
While it is true that a subquery could reference the output of another
subquery that happens to be a grouping-Var, that would be handled when
expanding grouping-Vars for that specific subquery.
2. prepjointree.c:1473
Here, we call flatten_join_alias_vars on the subquery's targetlist
during subquery flattening because once the the subquery's subqueries
are flattened, join alias entries may become arbitrary expressions
rather than simple Vars.
Again, I don't see a need for an analogous flatten_group_exprs call
here. Any subquery containing grouping-Vars must involve grouping,
and we don't flatten such subqueries to begin with.
3. planner.c:1309
Here, flatten_join_alias_vars is called within preprocess_expression
for various expressions. The analogous call to flatten_group_exprs
occurs at planner.c:1118. I believe we only need to call
flatten_group_exprs on the targetList and havingQual, as these are the
only places where grouping-Vars can appear.
Based on the above, I suspect whether we should expect the invocations
of flatten_group_exprs to be analogous to those of flatten_join_alias_vars.
- Richard
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Fwd: pg18 bug? SELECT query doesn't work
2026-01-08 04:03 Re: Fwd: pg18 bug? SELECT query doesn't work Tom Lane <[email protected]>
2026-01-08 13:30 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
@ 2026-01-09 09:52 ` Richard Guo <[email protected]>
2026-01-16 03:27 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Richard Guo @ 2026-01-09 09:52 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Eric Ridge <[email protected]>; Pg Hackers <[email protected]>
On Thu, Jan 8, 2026 at 10:30 PM Richard Guo <[email protected]> wrote:
> How about we add a comment to check_output_expressions() along the
> below lines?
I've worked on the comment a bit more in the attached patch, which
also includes my previously proposed code changes and some test cases.
I think this patch is suitable for fixing the current bug in the back
branches. We can use a separate patch for the more ambitious goal of
moving the push-down of subquery's restriction clauses into
subquery_planner().
Any thoughts?
- Richard
Attachments:
[application/octet-stream] v1-0001-Fix-unsafe-pushdown-of-quals-referencing-grouping.patch (10.3K, ../../CAMbWs48kk-f=7fCP5cCksZpc9n10CJEoe-edOoQfwMR6x0KNng@mail.gmail.com/2-v1-0001-Fix-unsafe-pushdown-of-quals-referencing-grouping.patch)
download | inline diff:
From a48b94bb7c8e60e15238bf291766b322d1601d03 Mon Sep 17 00:00:00 2001
From: Richard Guo <[email protected]>
Date: Fri, 9 Jan 2026 13:00:11 +0900
Subject: [PATCH v1] Fix unsafe pushdown of quals referencing grouping Vars
When checking a subquery's output expressions to see if it's safe to
push down an upper-level qual, check_output_expressions() previously
treated grouping Vars as opaque Vars. This implicitly assumed they
were stable and scalar.
However, a grouping Var's underlying expression corresponds to the
grouping clause, which may be volatile or set-returning. If an
upper-level qual references such an output column, pushing it down
into the subquery is unsafe. This can cause strange results due to
multiple evaluation of a volatile function, or introduce SRFs into
the subquery's WHERE/HAVING quals.
This patch teaches check_output_expressions() to look through grouping
Vars to their underlying expressions. This ensures that any
volatility or set-returning properties in the grouping clause are
detected, preventing the unsafe pushdown.
We do not need to recursively examine the Vars contained in these
underlying expressions. Even if they reference outputs from
lower-level subqueries (at any depth), those references are guaranteed
not to expand to volatile or set-returning functions, because
subqueries containing such functions in their targetlists are never
pulled up.
---
src/backend/optimizer/path/allpaths.c | 26 +++++-
src/backend/optimizer/util/var.c | 8 +-
src/test/regress/expected/subselect.out | 104 ++++++++++++++++++++++++
src/test/regress/sql/subselect.sql | 40 +++++++++
4 files changed, 175 insertions(+), 3 deletions(-)
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index 6e641c146a3..e00d1700817 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -4204,9 +4204,33 @@ recurse_pushdown_safe(Node *setOp, Query *topquery,
static void
check_output_expressions(Query *subquery, pushdown_safety_info *safetyInfo)
{
+ List *flattened_targetList = subquery->targetList;
ListCell *lc;
- foreach(lc, subquery->targetList)
+ /*
+ * We must be careful with grouping Vars and join alias Vars in the
+ * subquery's outputs, as they hide the underlying expressions.
+ *
+ * We need to expand grouping Vars to their underlying expressions (the
+ * grouping clauses) because the grouping expressions themselves might be
+ * volatile or set-returning. However, we do not need to expand join
+ * alias Vars, as their underlying structure does not introduce volatile
+ * or set-returning functions at the current level.
+ *
+ * In neither case do we need to recursively examine the Vars contained in
+ * these underlying expressions. Even if they reference outputs from
+ * lower-level subqueries (at any depth), those references are guaranteed
+ * not to expand to volatile or set-returning functions, because
+ * subqueries containing such functions in their targetlists are never
+ * pulled up.
+ */
+ if (subquery->hasGroupRTE)
+ {
+ flattened_targetList = (List *)
+ flatten_group_exprs(NULL, subquery, (Node *) subquery->targetList);
+ }
+
+ foreach(lc, flattened_targetList)
{
TargetEntry *tle = (TargetEntry *) lfirst(lc);
diff --git a/src/backend/optimizer/util/var.c b/src/backend/optimizer/util/var.c
index 99da622507b..5f22021ecca 100644
--- a/src/backend/optimizer/util/var.c
+++ b/src/backend/optimizer/util/var.c
@@ -959,10 +959,14 @@ flatten_join_alias_vars_mutator(Node *node,
* wrapper.
*
* NOTE: this is also used by ruleutils.c, to deparse one query parsetree back
- * to source text. For that use-case, root will be NULL, which is why we have
- * to pass the Query separately. We need the root itself only for preserving
+ * to source text, and by check_output_expressions() to check for unsafe
+ * pushdowns. For these use-cases, root will be NULL, which is why we have to
+ * pass the Query separately. We need the root itself only for preserving
* varnullingrels. We can avoid preserving varnullingrels in the ruleutils.c's
* usage because it does not make any difference to the deparsed source text.
+ * We can also avoid it in check_output_expressions() because that function
+ * only cares about the presence of volatile or set-returning functions, which
+ * is independent of the Vars' nullingrels.
*/
Node *
flatten_group_exprs(PlannerInfo *root, Query *query, Node *node)
diff --git a/src/test/regress/expected/subselect.out b/src/test/regress/expected/subselect.out
index 37ed59e73bf..2135d82884d 100644
--- a/src/test/regress/expected/subselect.out
+++ b/src/test/regress/expected/subselect.out
@@ -1925,6 +1925,110 @@ NOTICE: x = 9, y = 13
9 | 3
(3 rows)
+--
+-- check that an upper-level qual is not pushed down if it references a grouped
+-- Var whose underlying expression contains SRFs
+--
+explain (verbose, costs off)
+select * from
+ (select generate_series(1, ten) as g, count(*) from tenk1 group by 1) ss
+ where ss.g = 1;
+ QUERY PLAN
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+ Subquery Scan on ss
+ Output: ss.g, ss.count
+ Filter: (ss.g = 1)
+ -> HashAggregate
+ Output: (generate_series(1, tenk1.ten)), count(*)
+ Group Key: generate_series(1, tenk1.ten)
+ -> ProjectSet
+ Output: generate_series(1, tenk1.ten)
+ -> Seq Scan on public.tenk1
+ Output: tenk1.unique1, tenk1.unique2, tenk1.two, tenk1.four, tenk1.ten, tenk1.twenty, tenk1.hundred, tenk1.thousand, tenk1.twothousand, tenk1.fivethous, tenk1.tenthous, tenk1.odd, tenk1.even, tenk1.stringu1, tenk1.stringu2, tenk1.string4
+(10 rows)
+
+select * from
+ (select generate_series(1, ten) as g, count(*) from tenk1 group by 1) ss
+ where ss.g = 1;
+ g | count
+---+-------
+ 1 | 9000
+(1 row)
+
+--
+-- check that an upper-level qual is not pushed down if it references a grouped
+-- Var whose underlying expression contains volatile functions
+--
+alter function tattle(x int, y int) volatile;
+explain (verbose, costs off)
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+ QUERY PLAN
+------------------------------------------------------------
+ Subquery Scan on ss
+ Output: ss.v, ss.count
+ Filter: ss.v
+ -> GroupAggregate
+ Output: (tattle(3, tenk1.ten)), count(*)
+ Group Key: (tattle(3, tenk1.ten))
+ -> Sort
+ Output: (tattle(3, tenk1.ten))
+ Sort Key: (tattle(3, tenk1.ten))
+ -> Bitmap Heap Scan on public.tenk1
+ Output: tattle(3, tenk1.ten)
+ Recheck Cond: (tenk1.unique1 < 3)
+ -> Bitmap Index Scan on tenk1_unique1
+ Index Cond: (tenk1.unique1 < 3)
+(14 rows)
+
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+NOTICE: x = 3, y = 2
+NOTICE: x = 3, y = 1
+NOTICE: x = 3, y = 0
+ v | count
+---+-------
+ t | 3
+(1 row)
+
+-- if we pretend it's stable, we get different results:
+alter function tattle(x int, y int) stable;
+explain (verbose, costs off)
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+ QUERY PLAN
+------------------------------------------------------
+ GroupAggregate
+ Output: (tattle(3, tenk1.ten)), count(*)
+ Group Key: (tattle(3, tenk1.ten))
+ -> Sort
+ Output: (tattle(3, tenk1.ten))
+ Sort Key: (tattle(3, tenk1.ten))
+ -> Bitmap Heap Scan on public.tenk1
+ Output: tattle(3, tenk1.ten)
+ Recheck Cond: (tenk1.unique1 < 3)
+ Filter: tattle(3, tenk1.ten)
+ -> Bitmap Index Scan on tenk1_unique1
+ Index Cond: (tenk1.unique1 < 3)
+(12 rows)
+
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+NOTICE: x = 3, y = 2
+NOTICE: x = 3, y = 2
+NOTICE: x = 3, y = 1
+NOTICE: x = 3, y = 1
+NOTICE: x = 3, y = 0
+NOTICE: x = 3, y = 0
+ v | count
+---+-------
+ t | 3
+(1 row)
+
drop function tattle(x int, y int);
--
-- Test that LIMIT can be pushed to SORT through a subquery that just projects
diff --git a/src/test/regress/sql/subselect.sql b/src/test/regress/sql/subselect.sql
index 192a6f96b93..cadc3293687 100644
--- a/src/test/regress/sql/subselect.sql
+++ b/src/test/regress/sql/subselect.sql
@@ -952,6 +952,46 @@ select * from
(select 9 as x, unnest(array[1,2,3,11,12,13]) as u) ss
where tattle(x, u);
+--
+-- check that an upper-level qual is not pushed down if it references a grouped
+-- Var whose underlying expression contains SRFs
+--
+explain (verbose, costs off)
+select * from
+ (select generate_series(1, ten) as g, count(*) from tenk1 group by 1) ss
+ where ss.g = 1;
+
+select * from
+ (select generate_series(1, ten) as g, count(*) from tenk1 group by 1) ss
+ where ss.g = 1;
+
+--
+-- check that an upper-level qual is not pushed down if it references a grouped
+-- Var whose underlying expression contains volatile functions
+--
+alter function tattle(x int, y int) volatile;
+
+explain (verbose, costs off)
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+
+-- if we pretend it's stable, we get different results:
+alter function tattle(x int, y int) stable;
+
+explain (verbose, costs off)
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+
+select * from
+ (select tattle(3, ten) as v, count(*) from tenk1 where unique1 < 3 group by 1) ss
+ where ss.v;
+
drop function tattle(x int, y int);
--
--
2.39.5 (Apple Git-154)
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Fwd: pg18 bug? SELECT query doesn't work
2026-01-08 04:03 Re: Fwd: pg18 bug? SELECT query doesn't work Tom Lane <[email protected]>
2026-01-08 13:30 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-09 09:52 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
@ 2026-01-16 03:27 ` Richard Guo <[email protected]>
2026-01-17 16:18 ` Re: Fwd: pg18 bug? SELECT query doesn't work Eric Ridge <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Richard Guo @ 2026-01-16 03:27 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Eric Ridge <[email protected]>; Pg Hackers <[email protected]>
On Fri, Jan 9, 2026 at 6:52 PM Richard Guo <[email protected]> wrote:
> I've worked on the comment a bit more in the attached patch, which
> also includes my previously proposed code changes and some test cases.
>
> I think this patch is suitable for fixing the current bug in the back
> branches. We can use a separate patch for the more ambitious goal of
> moving the push-down of subquery's restriction clauses into
> subquery_planner().
I plan to push and backpatch this patch early next week, barring any
objections.
- Richard
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Fwd: pg18 bug? SELECT query doesn't work
2026-01-08 04:03 Re: Fwd: pg18 bug? SELECT query doesn't work Tom Lane <[email protected]>
2026-01-08 13:30 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-09 09:52 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-16 03:27 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
@ 2026-01-17 16:18 ` Eric Ridge <[email protected]>
2026-01-19 02:39 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Eric Ridge @ 2026-01-17 16:18 UTC (permalink / raw)
To: Richard Guo <[email protected]>; +Cc: Tom Lane <[email protected]>; Pg Hackers <[email protected]>
> I plan to push and backpatch this patch early next week, barring any
objections.
Thank you for your work on this. It’s sincerely appreciated.
eric
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Fwd: pg18 bug? SELECT query doesn't work
2026-01-08 04:03 Re: Fwd: pg18 bug? SELECT query doesn't work Tom Lane <[email protected]>
2026-01-08 13:30 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-09 09:52 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-16 03:27 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-17 16:18 ` Re: Fwd: pg18 bug? SELECT query doesn't work Eric Ridge <[email protected]>
@ 2026-01-19 02:39 ` Richard Guo <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Richard Guo @ 2026-01-19 02:39 UTC (permalink / raw)
To: Eric Ridge <[email protected]>; +Cc: Tom Lane <[email protected]>; Pg Hackers <[email protected]>
On Sun, Jan 18, 2026 at 1:18 AM Eric Ridge <[email protected]> wrote:
> > I plan to push and backpatch this patch early next week, barring any objections.
> Thank you for your work on this. It’s sincerely appreciated.
Pushed and backpatched. Thanks for the report, Eric. The fix will be
included in the next minor release this Feb.
- Richard
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-01-19 02:39 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-10-14 13:00 [PATCH v15 1/4] Prevent jumbling of every element in ArrayExpr Dmitrii Dolgov <[email protected]>
2026-01-08 04:03 Re: Fwd: pg18 bug? SELECT query doesn't work Tom Lane <[email protected]>
2026-01-08 13:30 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-09 09:52 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-16 03:27 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[email protected]>
2026-01-17 16:18 ` Re: Fwd: pg18 bug? SELECT query doesn't work Eric Ridge <[email protected]>
2026-01-19 02:39 ` Re: Fwd: pg18 bug? SELECT query doesn't work Richard Guo <[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