public inbox for [email protected]  
help / color / mirror / Atom feed
Feature Freeze
15+ messages / 9 participants
[nested] [flat]

* Feature Freeze
@ 2006-08-01 11:04 Bruce Momjian <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Bruce Momjian @ 2006-08-01 11:04 UTC (permalink / raw)
  To: pgsql-hackers

Now that it is August 1, we are in feature freeze.  During the next
month, all outstanding patches will be reviewed and hopefully applied.
After that, we will start preparing for beta, hopefully to start in
September or October.

-- 
  Bruce Momjian   [email protected]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +



^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Feature freeze
@ 2007-10-20 23:06 Bruce Momjian <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Bruce Momjian @ 2007-10-20 23:06 UTC (permalink / raw)
  To: pgsql-hackers

Many community members were disappointed that feature freeze took so
long, but based on the number of features added to 8.3 our feature
freeze duration was similar to previous releases.

I think our only big mistake was setting expectation that this would be
a short feature freeze.  We can be proud of the 8.3 release.

-- 
  Bruce Momjian  <[email protected]>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +



^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* [PATCH 1/2] Fixes to index_get_partition()
@ 2020-11-05 18:06 Justin Pryzby <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Justin Pryzby @ 2020-11-05 18:06 UTC (permalink / raw)

which was added at: a6da0047158b8a227f883aeed19eb7fcfbef11fb

free list in cases where there's no parent
use lsyscache: get_rel_relispartition()
---
 src/backend/catalog/partition.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 239ac017fa..4dfac39adf 100644
--- a/src/backend/catalog/partition.c
+++ b/src/backend/catalog/partition.c
@@ -170,13 +170,14 @@ index_get_partition(Relation partition, Oid indexId)
 		ReleaseSysCache(tup);
 		if (!ispartition)
 			continue;
-		if (get_partition_parent(lfirst_oid(l)) == indexId)
+		if (get_partition_parent(partIdx) == indexId)
 		{
 			list_free(idxlist);
 			return partIdx;
 		}
 	}
 
+	list_free(idxlist);
 	return InvalidOid;
 }
 
-- 
2.17.0


--6K2R/cS9K4qvcBNq
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0002-index_get_partition-use-lsyscache.patch"



^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Feature freeze
@ 2025-04-08 14:36 Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  0 siblings, 1 reply; 15+ messages in thread

From: Bruce Momjian @ 2025-04-08 14:36 UTC (permalink / raw)
  To: PostgreSQL-development <[email protected]>

Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):

	https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
	https://www.timeanddate.com/time/zones/aoe

and it is now 2:34 AM AoE, I guess we are now in feature freeze.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
@ 2025-04-08 14:59 ` Bruce Momjian <[email protected]>
  2025-04-08 15:13   ` Re: Feature freeze Daniel Gustafsson <[email protected]>
  2025-04-08 16:00   ` Re: Feature freeze Peter Eisentraut <[email protected]>
  0 siblings, 2 replies; 15+ messages in thread

From: Bruce Momjian @ 2025-04-08 14:59 UTC (permalink / raw)
  To: PostgreSQL-development <[email protected]>

On Tue, Apr  8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> Earth):
> 
> 	https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
> 	https://www.timeanddate.com/time/zones/aoe
> 
> and it is now 2:34 AM AoE, I guess we are now in feature freeze.

Frankly, I think the name "anywhere on Earth" is confusing, since it
really is "everywhere on Earth":

	https://en.wikipedia.org/wiki/Anywhere_on_Earth

	Anywhere on Earth (AoE) is a calendar designation that indicates
	that a period expires when the date passes everywhere on Earth.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
@ 2025-04-08 15:13   ` Daniel Gustafsson <[email protected]>
  2025-04-08 15:20     ` Re: Feature freeze Nathan Bossart <[email protected]>
  2025-04-09 06:56     ` Re: Feature freeze John Naylor <[email protected]>
  1 sibling, 2 replies; 15+ messages in thread

From: Daniel Gustafsson @ 2025-04-08 15:13 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: PostgreSQL-development <[email protected]>

> On 8 Apr 2025, at 16:59, Bruce Momjian <[email protected]> wrote:
> 
> On Tue, Apr  8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
>> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
>> Earth):
>> 
>> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
>> https://www.timeanddate.com/time/zones/aoe
>> 
>> and it is now 2:34 AM AoE, I guess we are now in feature freeze.
> 
> Frankly, I think the name "anywhere on Earth" is confusing, since it
> really is "everywhere on Earth":

I find both of the above needlessly confusing when we instead could use UTC
which is a more universally understood concept.

--
Daniel Gustafsson






^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 15:13   ` Re: Feature freeze Daniel Gustafsson <[email protected]>
@ 2025-04-08 15:20     ` Nathan Bossart <[email protected]>
  2025-04-08 15:53       ` Re: Feature freeze Bruce Momjian <[email protected]>
  1 sibling, 1 reply; 15+ messages in thread

From: Nathan Bossart @ 2025-04-08 15:20 UTC (permalink / raw)
  To: Daniel Gustafsson <[email protected]>; +Cc: Bruce Momjian <[email protected]>; PostgreSQL-development <[email protected]>

On Tue, Apr 08, 2025 at 05:13:15PM +0200, Daniel Gustafsson wrote:
>> On 8 Apr 2025, at 16:59, Bruce Momjian <[email protected]> wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
> 
> I find both of the above needlessly confusing when we instead could use UTC
> which is a more universally understood concept.

+1 for UTC.

-- 
nathan





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 15:13   ` Re: Feature freeze Daniel Gustafsson <[email protected]>
  2025-04-08 15:20     ` Re: Feature freeze Nathan Bossart <[email protected]>
@ 2025-04-08 15:53       ` Bruce Momjian <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Bruce Momjian @ 2025-04-08 15:53 UTC (permalink / raw)
  To: Peter Geoghegan <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Daniel Gustafsson <[email protected]>; PostgreSQL-development <[email protected]>

On Tue, Apr  8, 2025 at 11:45:09AM -0400, Peter Geoghegan wrote:
> On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart <[email protected]> wrote:
> > +1 for UTC.
> 
> +1, I think that AoE is needlessly obscure

We did have this discussion when AoE was chosen for PG 18 and the idea
was that as long as it is before April 18 midnight wherever you are, it
is not feature freeze yet.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 15:13   ` Re: Feature freeze Daniel Gustafsson <[email protected]>
@ 2025-04-09 06:56     ` John Naylor <[email protected]>
  1 sibling, 0 replies; 15+ messages in thread

From: John Naylor @ 2025-04-09 06:56 UTC (permalink / raw)
  To: Daniel Gustafsson <[email protected]>; +Cc: Bruce Momjian <[email protected]>; PostgreSQL-development <[email protected]>

On Tue, Apr 8, 2025 at 10:13 PM Daniel Gustafsson <[email protected]> wrote:
>
> I find both of the above needlessly confusing when we instead could use UTC
> which is a more universally understood concept.

Indeed, that's what the "U" stands for, after all. :-)

-- 
John Naylor
Amazon Web Services





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
@ 2025-04-08 16:00   ` Peter Eisentraut <[email protected]>
  2025-04-08 16:11     ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 16:24     ` Re: Feature freeze Nathan Bossart <[email protected]>
  1 sibling, 2 replies; 15+ messages in thread

From: Peter Eisentraut @ 2025-04-08 16:00 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; PostgreSQL-development <[email protected]>

On 08.04.25 16:59, Bruce Momjian wrote:
> On Tue, Apr  8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
>> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
>> Earth):
>>
>> 	https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
>> 	https://www.timeanddate.com/time/zones/aoe
>>
>> and it is now 2:34 AM AoE, I guess we are now in feature freeze.
> 
> Frankly, I think the name "anywhere on Earth" is confusing, since it
> really is "everywhere on Earth":
> 
> 	https://en.wikipedia.org/wiki/Anywhere_on_Earth
> 
> 	Anywhere on Earth (AoE) is a calendar designation that indicates
> 	that a period expires when the date passes everywhere on Earth.

Yes, that works intuitively when you specify that sometimes ends when a 
certain day ends, for example:

"The feature development phase ends at the end of day of April 7, AoE."

That means, everyone everywhere can just look up at their clock and see, 
it's still April 7, it's still going.  (Of course, others can then do 
the analysis and keep going until some time on April 8, but that would 
be sort of against the spirit.)

If you use it as a time zone with a time of day, it doesn't make 
intuitive sense.







^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 16:00   ` Re: Feature freeze Peter Eisentraut <[email protected]>
@ 2025-04-08 16:11     ` Bruce Momjian <[email protected]>
  2025-04-08 16:23       ` Re: Feature freeze Heikki Linnakangas <[email protected]>
  1 sibling, 1 reply; 15+ messages in thread

From: Bruce Momjian @ 2025-04-08 16:11 UTC (permalink / raw)
  To: Peter Eisentraut <[email protected]>; +Cc: PostgreSQL-development <[email protected]>

On Tue, Apr  8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr  8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> > > Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> > > Earth):
> > > 
> > > 	https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
> > > 	https://www.timeanddate.com/time/zones/aoe
> > > 
> > > and it is now 2:34 AM AoE, I guess we are now in feature freeze.
> > 
> > Frankly, I think the name "anywhere on Earth" is confusing, since it
> > really is "everywhere on Earth":
> > 
> > 	https://en.wikipedia.org/wiki/Anywhere_on_Earth
> > 
> > 	Anywhere on Earth (AoE) is a calendar designation that indicates
> > 	that a period expires when the date passes everywhere on Earth.
> 
> Yes, that works intuitively when you specify that sometimes ends when a
> certain day ends, for example:
> 
> "The feature development phase ends at the end of day of April 7, AoE."
> 
> That means, everyone everywhere can just look up at their clock and see,
> it's still April 7, it's still going.  (Of course, others can then do the
> analysis and keep going until some time on April 8, but that would be sort
> of against the spirit.)
> 
> If you use it as a time zone with a time of day, it doesn't make intuitive
> sense.

Well, they kind of did this by saying midnight on April 8 AoE, rather
than end-of-day in April 7 AoE.  Actually, I had originally said April 8
AoE and then was told I had to specify a time --- maybe the time was the
mistake, and we still have April 8 to add features.   ;-)

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 16:00   ` Re: Feature freeze Peter Eisentraut <[email protected]>
  2025-04-08 16:11     ` Re: Feature freeze Bruce Momjian <[email protected]>
@ 2025-04-08 16:23       ` Heikki Linnakangas <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Heikki Linnakangas @ 2025-04-08 16:23 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: PostgreSQL-development <[email protected]>

On 08/04/2025 19:11, Bruce Momjian wrote:
> On Tue, Apr  8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
>> On 08.04.25 16:59, Bruce Momjian wrote:
>>> On Tue, Apr  8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
>>>> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
>>>> Earth):
>>>>
>>>> 	https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
>>>> 	https://www.timeanddate.com/time/zones/aoe
>>>>
>>>> and it is now 2:34 AM AoE, I guess we are now in feature freeze.
>>>
>>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>>> really is "everywhere on Earth":
>>>
>>> 	https://en.wikipedia.org/wiki/Anywhere_on_Earth
>>>
>>> 	Anywhere on Earth (AoE) is a calendar designation that indicates
>>> 	that a period expires when the date passes everywhere on Earth.
>>
>> Yes, that works intuitively when you specify that sometimes ends when a
>> certain day ends, for example:
>>
>> "The feature development phase ends at the end of day of April 7, AoE."
>>
>> That means, everyone everywhere can just look up at their clock and see,
>> it's still April 7, it's still going.  (Of course, others can then do the
>> analysis and keep going until some time on April 8, but that would be sort
>> of against the spirit.)
>>
>> If you use it as a time zone with a time of day, it doesn't make intuitive
>> sense.
> 
> Well, they kind of did this by saying midnight on April 8 AoE, rather
> than end-of-day in April 7 AoE.  Actually, I had originally said April 8
> AoE and then was told I had to specify a time --- maybe the time was the
> mistake, and we still have April 8 to add features.   ;-)

At the end of the day (pun not intended), it doesn't matter much. 
Nothing special happens when the feature freeze begins. If some 
committers interpret it a little differently, it doesn't matter.

That said, +1 for using UTC in the future for clarity.

- Heikki







^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 16:00   ` Re: Feature freeze Peter Eisentraut <[email protected]>
@ 2025-04-08 16:24     ` Nathan Bossart <[email protected]>
  2025-04-08 16:39       ` Re: Feature freeze Nico Williams <[email protected]>
  1 sibling, 1 reply; 15+ messages in thread

From: Nathan Bossart @ 2025-04-08 16:24 UTC (permalink / raw)
  To: Peter Eisentraut <[email protected]>; +Cc: Bruce Momjian <[email protected]>; PostgreSQL-development <[email protected]>

On Tue, Apr 08, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
>> 	Anywhere on Earth (AoE) is a calendar designation that indicates
>> 	that a period expires when the date passes everywhere on Earth.
> 
> Yes, that works intuitively when you specify that sometimes ends when a
> certain day ends, for example:
> 
> "The feature development phase ends at the end of day of April 7, AoE."
> 
> That means, everyone everywhere can just look up at their clock and see,
> it's still April 7, it's still going.  (Of course, others can then do the
> analysis and keep going until some time on April 8, but that would be sort
> of against the spirit.)

I always forget if AoE is UTC+12 or UTC-12.  "Anywhere on Earth" sounds to
me like it means "the first moment it's this time anywhere on Earth," which
would be some point during April 7th for me.  So every year, I go to
Wikipedia, which reminds me it actually means "the moment this time has
passed everywhere on Earth."  At this point, I can finally convert to UTC
and then to my own time zone in my head.

If we just said April 8th, 12:00:00 UTC, I'd immediately know that my
entire April 7th was fair game.  Of course, I hope to usually be done
committing things much earlier...

-- 
nathan





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* Re: Feature freeze
  2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
  2025-04-08 16:00   ` Re: Feature freeze Peter Eisentraut <[email protected]>
  2025-04-08 16:24     ` Re: Feature freeze Nathan Bossart <[email protected]>
@ 2025-04-08 16:39       ` Nico Williams <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Nico Williams @ 2025-04-08 16:39 UTC (permalink / raw)
  To: Nathan Bossart <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Bruce Momjian <[email protected]>; PostgreSQL-development <[email protected]>

On Tue, Apr 08, 2025 at 11:24:39AM -0500, Nathan Bossart wrote:
> I always forget if AoE is UTC+12 or UTC-12.  [...]

One isn't supposed to think "is the freeze on everywhere", just "is the
freeze on for me" and "is the freeze on for this particular contribution
(check the date header)".

Nico
-- 





^ permalink  raw  reply  [nested|flat] 15+ messages in thread

* [PATCH] REPACK CONCURRENTLY: Initialize the range table more honestly
@ 2026-07-03 10:47 Álvaro Herrera <[email protected]>
  0 siblings, 0 replies; 15+ messages in thread

From: Álvaro Herrera @ 2026-07-03 10:47 UTC (permalink / raw)

We were skipping a bunch of things that are mostly unnecessary for
REPACK.  However, one thing that seems would be better to pass closer to
truth, is the updatedCols bitmapset in the range table entry for the
repacked table.  Cons up an RTE and install it into the EState.

This only has an effect on btree indexes, because certain operations are
optimized in the case of unchanged columns; and even then, correctnesss
is not being compromised.

The values we pass after this commit are not fully trustworthy either,
because we simply say "all columns were updated" for all insert/updates,
regardless of whether their values were actually modified or not.
However, this way we err to the side of caution rather than to the
opposite direction as we were originally doing.  This could be refined
in the future, but there's a trade-off: determining whether the column
was in fact updated could be expensive.

Author: Antonin Houska <[email protected]>
Reviewed-by: Ewan Young <[email protected]>
Backpatch-through: 19
Discussion: https://postgr.es/m/18222.1782126731@localhost
---
 src/backend/commands/repack.c | 57 +++++++++++++++++++++++++++++++++--
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index 83a49afe7e1..faa07d1a118 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -63,6 +63,7 @@
 #include "libpq/pqmq.h"
 #include "miscadmin.h"
 #include "optimizer/optimizer.h"
+#include "parser/parse_relation.h"
 #include "pgstat.h"
 #include "replication/logicalrelation.h"
 #include "storage/bufmgr.h"
@@ -3019,8 +3020,60 @@ initialize_change_context(ChangeContext *chgcxt,
 	/* Only initialize fields needed by ExecInsertIndexTuples(). */
 	chgcxt->cc_estate = CreateExecutorState();
 
-	chgcxt->cc_rri = (ResultRelInfo *) palloc(sizeof(ResultRelInfo));
-	InitResultRelInfo(chgcxt->cc_rri, relation, 0, 0, 0);
+	/*
+	 * Set up a range table for the executor, containing our repacked table as
+	 * its only member.
+	 */
+	{
+		RangeTblEntry *rte;
+		TupleDesc	desc = RelationGetDescr(relation);
+		List	   *perminfos = NIL;
+		Bitmapset  *updatedCols = NULL;
+		RTEPermissionInfo *perminfo;
+
+		/*
+		 * For our use, the RTE only needs to have perminfoindex initialized,
+		 * but there's no reason to not set the fields whose values we have at
+		 * hand.
+		 */
+		rte = makeNode(RangeTblEntry);
+		rte->rtekind = RTE_RELATION;
+		rte->relid = RelationGetRelid(relation);
+		rte->relkind = RelationGetForm(relation)->relkind;
+		/* Create the RTEPermissionInfo instance (and set ->perminfoindex). */
+		addRTEPermissionInfo(&perminfos, rte);
+
+		/*
+		 * Initialize updatedCols to show that all columns are updated.  This
+		 * is of course not necessarily true, and we cannot know this early;
+		 * but this is only used by ExecInsertIndexTuples to flag index
+		 * updates with no logical value changes, so if it's wrong, nothing
+		 * terribly bad happens. We may want to improve this someday though.
+		 *
+		 * Don't claim that dropped columns are changed though.
+		 */
+		for (int i = 0; i < desc->natts; i++)
+		{
+			CompactAttribute *attr = TupleDescCompactAttr(desc, i);
+
+			if (attr->attisdropped)
+				continue;
+			updatedCols = bms_add_member(updatedCols,
+										 i + 1 - FirstLowInvalidHeapAttributeNumber);
+		}
+
+		/* install updatedCols in the right place */
+		perminfo = getRTEPermissionInfo(perminfos, rte);
+		perminfo->updatedCols = updatedCols;
+
+		/* finally we can initialize the range table proper */
+		ExecInitRangeTable(chgcxt->cc_estate, list_make1(rte), perminfos,
+						   bms_make_singleton(1));
+	}
+
+	/* Set up our ResultRelInfo to use for index updates */
+	chgcxt->cc_rri = makeNode(ResultRelInfo);
+	InitResultRelInfo(chgcxt->cc_rri, relation, 1, NULL, 0);
 	ExecOpenIndices(chgcxt->cc_rri, false);
 
 	/*
-- 
2.47.3


--pi6rmivyoaehyqn6--





^ permalink  raw  reply  [nested|flat] 15+ messages in thread


end of thread, other threads:[~2026-07-03 10:47 UTC | newest]

Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-08-01 11:04 Feature Freeze Bruce Momjian <[email protected]>
2007-10-20 23:06 Feature freeze Bruce Momjian <[email protected]>
2020-11-05 18:06 [PATCH 1/2] Fixes to index_get_partition() Justin Pryzby <[email protected]>
2025-04-08 14:36 Feature freeze Bruce Momjian <[email protected]>
2025-04-08 14:59 ` Re: Feature freeze Bruce Momjian <[email protected]>
2025-04-08 15:13   ` Re: Feature freeze Daniel Gustafsson <[email protected]>
2025-04-08 15:20     ` Re: Feature freeze Nathan Bossart <[email protected]>
2025-04-08 15:53       ` Re: Feature freeze Bruce Momjian <[email protected]>
2025-04-09 06:56     ` Re: Feature freeze John Naylor <[email protected]>
2025-04-08 16:00   ` Re: Feature freeze Peter Eisentraut <[email protected]>
2025-04-08 16:11     ` Re: Feature freeze Bruce Momjian <[email protected]>
2025-04-08 16:23       ` Re: Feature freeze Heikki Linnakangas <[email protected]>
2025-04-08 16:24     ` Re: Feature freeze Nathan Bossart <[email protected]>
2025-04-08 16:39       ` Re: Feature freeze Nico Williams <[email protected]>
2026-07-03 10:47 [PATCH] REPACK CONCURRENTLY: Initialize the range table more honestly Álvaro Herrera <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox