agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedRe: shared-memory based stats collector
334+ messages / 4 participants
[nested] [flat]
* Re: shared-memory based stats collector
@ 2020-09-03 17:16 Stephen Frost <sfrost@snowman.net>
2020-09-07 02:04 ` Re: shared-memory based stats collector Michael Paquier <michael@paquier.xyz>
2020-09-07 13:46 ` Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
2020-09-08 08:01 ` Re: shared-memory based stats collector Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 3 replies; 334+ messages in thread
From: Stephen Frost @ 2020-09-03 17:16 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; +Cc: alvherre@2ndquadrant.com; andres@anarazel.de; michael@paquier.xyz; thomas.munro@gmail.com; tomas.vondra@2ndquadrant.com; ah@cybertec.at; magnus@hagander.net; robertmhaas@gmail.com; tgl@sss.pgh.pa.us; pgsql-hackers
Greetings,
* Kyotaro Horiguchi (horikyota.ntt@gmail.com) wrote:
> At Mon, 01 Jun 2020 18:00:01 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > Rebased on the current HEAD. 36ac359d36 conflicts with this. Tranche
>
> Hmm. This conflicts with 0fd2a79a63. Reabsed on it.
Thanks for working on this and keeping it updated!
I've started taking a look and at least right off...
> >From 4926e50e7635548f86dcd0d36cbf56d168a5d242 Mon Sep 17 00:00:00 2001
> From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
> Date: Mon, 16 Mar 2020 17:15:35 +0900
> Subject: [PATCH v35 1/7] Use standard crash handler in archiver.
>
> The commit 8e19a82640 changed SIGQUIT handler of almost all processes
> not to run atexit callbacks for safety. Archiver process should behave
> the same way for the same reason. Exit status changes 1 to 2 but that
> doesn't make any behavioral change.
Shouldn't this:
a) be back-patched, as the other change was
b) also include a change to have the stats collector (which I realize is
removed later on in this patch set, but we're talking about fixing
existing things..) for the same reason, and because there isn't much
point in trying to write out the stats after we get a SIGQUIT, since
we're just going to blow them away again since we're going to go
through crash recovery..?
Might be good to have a separate thread to address these changes.
I've looked through (some of) this thread and through the patches also
and hope to provide a review of the bits that should be targetting v14
(unlike the above) soon.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../20200903171659.GO29590@tamriel.snowman.net/2-signature.asc)
download
^ permalink raw reply [nested|flat] 334+ messages in thread
* Re: shared-memory based stats collector
2020-09-03 17:16 Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
@ 2020-09-07 02:04 ` Michael Paquier <michael@paquier.xyz>
2 siblings, 0 replies; 334+ messages in thread
From: Michael Paquier @ 2020-09-07 02:04 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; alvherre@2ndquadrant.com; andres@anarazel.de; thomas.munro@gmail.com; tomas.vondra@2ndquadrant.com; ah@cybertec.at; magnus@hagander.net; robertmhaas@gmail.com; tgl@sss.pgh.pa.us; pgsql-hackers
On Thu, Sep 03, 2020 at 01:16:59PM -0400, Stephen Frost wrote:
> Shouldn't this:
>
> a) be back-patched, as the other change was
0001 is just a piece of refactoring, so I see no strong argument in
favor of a backpatch, IMHO.
> b) also include a change to have the stats collector (which I realize is
> removed later on in this patch set, but we're talking about fixing
> existing things..) for the same reason, and because there isn't much
> point in trying to write out the stats after we get a SIGQUIT, since
> we're just going to blow them away again since we're going to go
> through crash recovery..?
>
> Might be good to have a separate thread to address these changes.
>
> I've looked through (some of) this thread and through the patches also
> and hope to provide a review of the bits that should be targetting v14
> (unlike the above) soon.
The latest patch set fails to apply and the CF bot is complaining, so
a rebase is needed. I have switched the patch as waiting on author.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../20200907020419.GC2455@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 334+ messages in thread
* Re: shared-memory based stats collector
2020-09-03 17:16 Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
@ 2020-09-07 13:46 ` Stephen Frost <sfrost@snowman.net>
2 siblings, 0 replies; 334+ messages in thread
From: Stephen Frost @ 2020-09-07 13:46 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; Michael Paquier <michael@paquier.xyz>; +Cc: alvherre@2ndquadrant.com; andres@anarazel.de; thomas.munro@gmail.com; tomas.vondra@2ndquadrant.com; ah@cybertec.at; magnus@hagander.net; robertmhaas@gmail.com; tgl@sss.pgh.pa.us; pgsql-hackers
Greetings,
* Stephen Frost (sfrost@snowman.net) wrote:
> * Kyotaro Horiguchi (horikyota.ntt@gmail.com) wrote:
> > The commit 8e19a82640 changed SIGQUIT handler of almost all processes
> > not to run atexit callbacks for safety. Archiver process should behave
> > the same way for the same reason. Exit status changes 1 to 2 but that
> > doesn't make any behavioral change.
>
> Shouldn't this:
>
> a) be back-patched, as the other change was
> b) also include a change to have the stats collector (which I realize is
> removed later on in this patch set, but we're talking about fixing
> existing things..) for the same reason, and because there isn't much
> point in trying to write out the stats after we get a SIGQUIT, since
> we're just going to blow them away again since we're going to go
> through crash recovery..?
* Michael Paquier (michael@paquier.xyz) wrote:
> 0001 is just a piece of refactoring, so I see no strong argument in
> favor of a backpatch, IMHO.
No, 0001 changes the SIGQUIT handler for the archiver process, which is
what 8e19a82640 was about changing for a bunch of the other subprocesses
and which was back-patched all the way, so I'm a bit confused about why
you're saying it's just refactoring..?
Note that exit() and _exit() aren't the same, and the latter is what's
now being used in SignalHandlerForCrashExit.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../20200907134602.GA29590@tamriel.snowman.net/2-signature.asc)
download
^ permalink raw reply [nested|flat] 334+ messages in thread
* Re: shared-memory based stats collector
2020-09-03 17:16 Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
@ 2020-09-08 08:01 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2020-09-08 08:55 ` Re: shared-memory based stats collector Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2 siblings, 1 reply; 334+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-08 08:01 UTC (permalink / raw)
To: sfrost@snowman.net; +Cc: alvherre@2ndquadrant.com; andres@anarazel.de; michael@paquier.xyz; thomas.munro@gmail.com; tomas.vondra@2ndquadrant.com; ah@cybertec.at; magnus@hagander.net; robertmhaas@gmail.com; tgl@sss.pgh.pa.us; pgsql-hackers
At Thu, 3 Sep 2020 13:16:59 -0400, Stephen Frost <sfrost@snowman.net> wrote in
> Greetings,
>
> * Kyotaro Horiguchi (horikyota.ntt@gmail.com) wrote:
> > At Mon, 01 Jun 2020 18:00:01 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > > Rebased on the current HEAD. 36ac359d36 conflicts with this. Tranche
> >
> > Hmm. This conflicts with 0fd2a79a63. Reabsed on it.
>
> Thanks for working on this and keeping it updated!
>
> I've started taking a look and at least right off...
>
> > >From 4926e50e7635548f86dcd0d36cbf56d168a5d242 Mon Sep 17 00:00:00 2001
> > From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
> > Date: Mon, 16 Mar 2020 17:15:35 +0900
> > Subject: [PATCH v35 1/7] Use standard crash handler in archiver.
> >
> > The commit 8e19a82640 changed SIGQUIT handler of almost all processes
> > not to run atexit callbacks for safety. Archiver process should behave
> > the same way for the same reason. Exit status changes 1 to 2 but that
> > doesn't make any behavioral change.
>
> Shouldn't this:
>
> a) be back-patched, as the other change was
> b) also include a change to have the stats collector (which I realize is
> removed later on in this patch set, but we're talking about fixing
> existing things..) for the same reason, and because there isn't much
> point in trying to write out the stats after we get a SIGQUIT, since
> we're just going to blow them away again since we're going to go
> through crash recovery..?
>
> Might be good to have a separate thread to address these changes.
+1
> I've looked through (some of) this thread and through the patches also
> and hope to provide a review of the bits that should be targetting v14
> (unlike the above) soon.
Thanks. Current the patch is found to lead to write contention heavier
than the current stats collector when nearly a thousand backend
heavily write to the same table. I need to address that.
- Collect stats via sockets (in the same way as the current implement)
and write/read to/from shared memory.
- Use our own lock-free (maybe) ring-buffer before stats-write enters
lock-waiting mode, then new stats collector(!) process consumes the
queue.
- Some other measures..
Anyway, I'll post a rebased version soon.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 334+ messages in thread
* Re: shared-memory based stats collector
2020-09-03 17:16 Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
2020-09-08 08:01 ` Re: shared-memory based stats collector Kyotaro Horiguchi <horikyota.ntt@gmail.com>
@ 2020-09-08 08:55 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2020-09-09 08:01 ` Re: shared-memory based stats collector Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 334+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-08 08:55 UTC (permalink / raw)
To: sfrost@snowman.net; +Cc: alvherre@2ndquadrant.com; andres@anarazel.de; michael@paquier.xyz; thomas.munro@gmail.com; tomas.vondra@2ndquadrant.com; ah@cybertec.at; magnus@hagander.net; robertmhaas@gmail.com; tgl@sss.pgh.pa.us; pgsql-hackers
At Tue, 08 Sep 2020 17:01:47 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> At Thu, 3 Sep 2020 13:16:59 -0400, Stephen Frost <sfrost@snowman.net> wrote in> > I've looked through (some of) this thread and through the patches also
> > and hope to provide a review of the bits that should be targetting v14
> > (unlike the above) soon.
>
> Thanks. Current the patch is found to lead to write contention heavier
> than the current stats collector when nearly a thousand backend
> heavily write to the same table. I need to address that.
>
> - Collect stats via sockets (in the same way as the current implement)
> and write/read to/from shared memory.
>
> - Use our own lock-free (maybe) ring-buffer before stats-write enters
> lock-waiting mode, then new stats collector(!) process consumes the
> queue.
>
> - Some other measures..
>
> Anyway, I'll post a rebased version soon.
This is that. I'll continue seeking a way to solve the contention.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 334+ messages in thread
* Re: shared-memory based stats collector
2020-09-03 17:16 Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
2020-09-08 08:01 ` Re: shared-memory based stats collector Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2020-09-08 08:55 ` Re: shared-memory based stats collector Kyotaro Horiguchi <horikyota.ntt@gmail.com>
@ 2020-09-09 08:01 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 0 replies; 334+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-09 08:01 UTC (permalink / raw)
To: sfrost@snowman.net; +Cc: alvherre@2ndquadrant.com; andres@anarazel.de; michael@paquier.xyz; thomas.munro@gmail.com; tomas.vondra@2ndquadrant.com; ah@cybertec.at; magnus@hagander.net; robertmhaas@gmail.com; tgl@sss.pgh.pa.us; pgsql-hackers
At Tue, 08 Sep 2020 17:55:57 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> At Tue, 08 Sep 2020 17:01:47 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > At Thu, 3 Sep 2020 13:16:59 -0400, Stephen Frost <sfrost@snowman.net> wrote in> > I've looked through (some of) this thread and through the patches also
> > > and hope to provide a review of the bits that should be targetting v14
> > > (unlike the above) soon.
> >
> > Thanks. Current the patch is found to lead to write contention heavier
> > than the current stats collector when nearly a thousand backend
> > heavily write to the same table. I need to address that.
> >
> > - Collect stats via sockets (in the same way as the current implement)
> > and write/read to/from shared memory.
> >
> > - Use our own lock-free (maybe) ring-buffer before stats-write enters
> > lock-waiting mode, then new stats collector(!) process consumes the
> > queue.
> >
> > - Some other measures..
- Make dshash search less frequent. To find the actual source of the
contension, We're going to measure performance with the attached on
top of the latest patch let sessions cache the result of dshash
searches for the session lifetime. (table-dropping vacuum clears the
local hash.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
* [PATCH 2/2] Provide the executor with information on updated columns.
@ 2026-07-01 13:18 Antonin Houska <ah@cybertec.at>
0 siblings, 0 replies; 334+ messages in thread
From: Antonin Houska @ 2026-07-01 13:18 UTC (permalink / raw)
When replaying data changes, REPACK calls ExecInsertIndexTuples() for each
INSERT and UPDATE. In the latter case, the function needs to determine the
value of the 'indexUnchanged' hint for the index AM. (The hint is always false
for INSERT.) Therefore, REPACK is supposed to specify which columns are
changed by the UPDATE.
So far, REPACK missed to specify the set of updated columns, so the
'indexUnchanged' hint could incorrectly evaluate to true. Although it should
not affect correctness, it can make the index AM use optimizations that are
not appropriate. Ideally, we should compute the set of updated columns for
each individual UPDATE, however the comparison of the old and new tuple might
add too much overhead.
This patch initializes the set as if all columns were updated. Thus
'indexUnchanged' always evaluates to false. This way the index AM never uses
the related optimizations. It might result in worse structure of the index,
however it seems better to not use the optimizations than to misuse them.
---
src/backend/commands/repack.c | 40 ++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index c9b0c047477..f37bb9a21af 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -62,6 +62,7 @@
#include "libpq/pqmq.h"
#include "miscadmin.h"
#include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
@@ -3005,13 +3006,50 @@ static void
initialize_change_context(ChangeContext *chgcxt,
Relation relation, Oid ident_index_id)
{
+ Bitmapset *updatedCols = NULL;
+ RangeTblEntry *rte;
+ List *perminfos = NIL;
+ RTEPermissionInfo *perminfo;
+
chgcxt->cc_rel = relation;
/* Only initialize fields needed by ExecInsertIndexTuples(). */
chgcxt->cc_estate = CreateExecutorState();
+ /*
+ * Initialize updatedCols.
+ *
+ * The point is that ExecInsertIndexTuples() should not pass the
+ * indexUnchanged hint to the index AM unless there's a reason to do
+ * so. For simplicity, we consider all columns updated.
+ *
+ * XXX Should we spend more effort to compare the old and new tuple when
+ * replaying UPDATE, or at least exclude unchanged TOAST values, like we
+ * do in logicalrep_write_tuple()?
+ */
+ for (int i = 0; i < RelationGetDescr(relation)->natts; i++)
+ updatedCols = bms_add_member(updatedCols,
+ i + 1 - FirstLowInvalidHeapAttributeNumber);
+
+ /*
+ * In this case, RTE only needs to have ->perminfoindex initialized, but
+ * there's no reason to not set the fields whose values we have at hand.
+ */
+ rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = RelationGetRelid(relation);
+ rte->relkind = RelationGetForm(relation)->relkind;
+ /* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+ addRTEPermissionInfo(&perminfos, rte);
+ /* Make updatedCols available to the executor functions. */
+ perminfo = getRTEPermissionInfo(perminfos, rte);
+ perminfo->updatedCols = updatedCols;
+
+ ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+ bms_make_singleton(1));
+
chgcxt->cc_rri = makeNode(ResultRelInfo);
- InitResultRelInfo(chgcxt->cc_rri, relation, 0, NULL, 0);
+ InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
ExecOpenIndices(chgcxt->cc_rri, false);
/*
--
2.52.0
--=-=-=--
^ permalink raw reply [nested|flat] 334+ messages in thread
end of thread, other threads:[~2026-07-01 13:18 UTC | newest]
Thread overview: 334+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-09-03 17:16 Re: shared-memory based stats collector Stephen Frost <sfrost@snowman.net>
2020-09-07 02:04 ` Michael Paquier <michael@paquier.xyz>
2020-09-07 13:46 ` Stephen Frost <sfrost@snowman.net>
2020-09-08 08:01 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2020-09-08 08:55 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2020-09-09 08:01 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
2026-07-01 13:18 [PATCH 2/2] Provide the executor with information on updated columns. Antonin Houska <ah@cybertec.at>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox