agora inbox for [email protected]
help / color / mirror / Atom feed[PATCH v50 2/8] Rename cluster.c/h -> repack.c/h
320+ messages / 2 participants
[nested] [flat]
* [PATCH v50 2/8] Rename cluster.c/h -> repack.c/h
@ 2026-03-31 16:55 Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Álvaro Herrera @ 2026-03-31 16:55 UTC (permalink / raw)
---
src/backend/commands/Makefile | 2 +-
src/backend/commands/matview.c | 2 +-
src/backend/commands/meson.build | 2 +-
src/backend/commands/{cluster.c => repack.c} | 6 +++---
src/backend/commands/tablecmds.c | 2 +-
src/backend/commands/vacuum.c | 6 +++---
src/backend/storage/ipc/procsignal.c | 1 +
src/backend/tcop/postgres.c | 1 +
src/backend/tcop/utility.c | 2 +-
src/include/commands/{cluster.h => repack.h} | 12 ++++++------
10 files changed, 19 insertions(+), 17 deletions(-)
rename src/backend/commands/{cluster.c => repack.c} (99%)
rename src/include/commands/{cluster.h => repack.h} (90%)
diff --git a/src/backend/commands/Makefile b/src/backend/commands/Makefile
index c10fdba2bbb..fe1bba3a9b9 100644
--- a/src/backend/commands/Makefile
+++ b/src/backend/commands/Makefile
@@ -18,7 +18,6 @@ OBJS = \
amcmds.o \
analyze.o \
async.o \
- cluster.o \
collationcmds.o \
comment.o \
constraint.o \
@@ -51,6 +50,7 @@ OBJS = \
proclang.o \
propgraphcmds.o \
publicationcmds.o \
+ repack.o \
schemacmds.o \
seclabel.o \
sequence.o \
diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c
index d3be8939011..5db4fe75dce 100644
--- a/src/backend/commands/matview.c
+++ b/src/backend/commands/matview.c
@@ -24,8 +24,8 @@
#include "catalog/namespace.h"
#include "catalog/pg_am.h"
#include "catalog/pg_opclass.h"
-#include "commands/cluster.h"
#include "commands/matview.h"
+#include "commands/repack.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
#include "executor/executor.h"
diff --git a/src/backend/commands/meson.build b/src/backend/commands/meson.build
index 90c7e37a429..f624aae74af 100644
--- a/src/backend/commands/meson.build
+++ b/src/backend/commands/meson.build
@@ -6,7 +6,6 @@ backend_sources += files(
'amcmds.c',
'analyze.c',
'async.c',
- 'cluster.c',
'collationcmds.c',
'comment.c',
'constraint.c',
@@ -39,6 +38,7 @@ backend_sources += files(
'proclang.c',
'propgraphcmds.c',
'publicationcmds.c',
+ 'repack.c',
'schemacmds.c',
'seclabel.c',
'sequence.c',
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/repack.c
similarity index 99%
rename from src/backend/commands/cluster.c
rename to src/backend/commands/repack.c
index f241e18b153..20f0a572236 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/repack.c
@@ -1,6 +1,6 @@
/*-------------------------------------------------------------------------
*
- * cluster.c
+ * repack.c
* REPACK a table; formerly known as CLUSTER. VACUUM FULL also uses
* parts of this code.
*
@@ -10,7 +10,7 @@
*
*
* IDENTIFICATION
- * src/backend/commands/cluster.c
+ * src/backend/commands/repack.c
*
*-------------------------------------------------------------------------
*/
@@ -33,9 +33,9 @@
#include "catalog/pg_am.h"
#include "catalog/pg_inherits.h"
#include "catalog/toasting.h"
-#include "commands/cluster.h"
#include "commands/defrem.h"
#include "commands/progress.h"
+#include "commands/repack.h"
#include "commands/tablecmds.h"
#include "commands/vacuum.h"
#include "miscadmin.h"
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 0ce2e81f9c2..e2882a50b3b 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -57,10 +57,10 @@
#include "catalog/storage.h"
#include "catalog/storage_xlog.h"
#include "catalog/toasting.h"
-#include "commands/cluster.h"
#include "commands/comment.h"
#include "commands/defrem.h"
#include "commands/event_trigger.h"
+#include "commands/repack.h"
#include "commands/sequence.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 0ed363d1c85..b179b62b5c8 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -9,7 +9,7 @@
*
* VACUUM for heap AM is implemented in vacuumlazy.c, parallel vacuum in
* vacuumparallel.c, ANALYZE in analyze.c, and VACUUM FULL is a variant of
- * CLUSTER, handled in cluster.c.
+ * REPACK, handled in repack.c.
*
*
* Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
@@ -38,9 +38,9 @@
#include "catalog/pg_database.h"
#include "catalog/pg_inherits.h"
#include "commands/async.h"
-#include "commands/cluster.h"
#include "commands/defrem.h"
#include "commands/progress.h"
+#include "commands/repack.h"
#include "commands/vacuum.h"
#include "miscadmin.h"
#include "nodes/makefuncs.h"
@@ -2293,7 +2293,7 @@ vacuum_rel(Oid relid, RangeVar *relation, VacuumParams params,
if ((params.options & VACOPT_VERBOSE) != 0)
cluster_params.options |= CLUOPT_VERBOSE;
- /* VACUUM FULL is a variant of REPACK; see cluster.c */
+ /* VACUUM FULL is a variant of REPACK; see repack.c */
cluster_rel(REPACK_COMMAND_VACUUMFULL, rel, InvalidOid,
&cluster_params);
/* cluster_rel closes the relation, but keeps lock */
diff --git a/src/backend/storage/ipc/procsignal.c b/src/backend/storage/ipc/procsignal.c
index 7e017c8d53b..7cef6e43661 100644
--- a/src/backend/storage/ipc/procsignal.c
+++ b/src/backend/storage/ipc/procsignal.c
@@ -19,6 +19,7 @@
#include "access/parallel.h"
#include "commands/async.h"
+#include "commands/repack.h"
#include "miscadmin.h"
#include "pgstat.h"
#include "port/pg_bitutils.h"
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 10be60011ad..9fbaa5c00f0 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -39,6 +39,7 @@
#include "commands/event_trigger.h"
#include "commands/explain_state.h"
#include "commands/prepare.h"
+#include "commands/repack.h"
#include "common/pg_prng.h"
#include "jit/jit.h"
#include "libpq/libpq.h"
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 2b609bfc824..5f8c766c4be 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -26,7 +26,6 @@
#include "catalog/toasting.h"
#include "commands/alter.h"
#include "commands/async.h"
-#include "commands/cluster.h"
#include "commands/collationcmds.h"
#include "commands/comment.h"
#include "commands/conversioncmds.h"
@@ -46,6 +45,7 @@
#include "commands/proclang.h"
#include "commands/propgraphcmds.h"
#include "commands/publicationcmds.h"
+#include "commands/repack.h"
#include "commands/schemacmds.h"
#include "commands/seclabel.h"
#include "commands/sequence.h"
diff --git a/src/include/commands/cluster.h b/src/include/commands/repack.h
similarity index 90%
rename from src/include/commands/cluster.h
rename to src/include/commands/repack.h
index d6b62c747e8..85061158b0c 100644
--- a/src/include/commands/cluster.h
+++ b/src/include/commands/repack.h
@@ -1,17 +1,17 @@
/*-------------------------------------------------------------------------
*
- * cluster.h
- * header file for postgres cluster command stuff
+ * repack.h
+ * header file for the REPACK command
*
* Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
* Portions Copyright (c) 1994-5, Regents of the University of California
*
- * src/include/commands/cluster.h
+ * src/include/commands/repack.h
*
*-------------------------------------------------------------------------
*/
-#ifndef CLUSTER_H
-#define CLUSTER_H
+#ifndef REPACK_H
+#define REPACK_H
#include "nodes/parsenodes.h"
#include "parser/parse_node.h"
@@ -52,4 +52,4 @@ extern void finish_heap_swap(Oid OIDOldHeap, Oid OIDNewHeap,
MultiXactId cutoffMulti,
char newrelpersistence);
-#endif /* CLUSTER_H */
+#endif /* REPACK_H */
--
2.47.3
--brnevsqjnuzpyok4
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v50-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <[email protected]>
0 siblings, 0 replies; 320+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 320+ messages in thread
end of thread, other threads:[~2026-07-01 13:18 UTC | newest]
Thread overview: 320+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-31 16:55 [PATCH v50 2/8] Rename cluster.c/h -> repack.c/h Álvaro Herrera <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[email protected]>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <[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