public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v7 6/7] Preserve indisclustered on children of clustered, partitioned indexes 2+ messages / 2 participants [nested] [flat]
* [PATCH v7 6/7] Preserve indisclustered on children of clustered, partitioned indexes @ 2020-10-07 01:40 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2020-10-07 01:40 UTC (permalink / raw) Note, this takes a parentIndex, but that wasn't previously used ... UpdateIndexRelation(Oid indexoid, Oid heapoid, Oid parentIndexId, --- src/backend/catalog/index.c | 2 +- src/test/regress/expected/cluster.out | 12 ++++++++++++ src/test/regress/sql/cluster.sql | 4 ++++ 3 files changed, 17 insertions(+), 1 deletion(-) diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index 1cb9172a5f..3611da45e6 100644 --- a/src/backend/catalog/index.c +++ b/src/backend/catalog/index.c @@ -604,7 +604,7 @@ UpdateIndexRelation(Oid indexoid, values[Anum_pg_index_indisprimary - 1] = BoolGetDatum(primary); values[Anum_pg_index_indisexclusion - 1] = BoolGetDatum(isexclusion); values[Anum_pg_index_indimmediate - 1] = BoolGetDatum(immediate); - values[Anum_pg_index_indisclustered - 1] = BoolGetDatum(false); + values[Anum_pg_index_indisclustered - 1] = BoolGetDatum(OidIsValid(parentIndexId) && get_index_isclustered(parentIndexId)); values[Anum_pg_index_indisvalid - 1] = BoolGetDatum(isvalid); values[Anum_pg_index_indcheckxmin - 1] = BoolGetDatum(false); values[Anum_pg_index_indisready - 1] = BoolGetDatum(isready); diff --git a/src/test/regress/expected/cluster.out b/src/test/regress/expected/cluster.out index e7f0889743..a3943c13f5 100644 --- a/src/test/regress/expected/cluster.out +++ b/src/test/regress/expected/cluster.out @@ -581,6 +581,18 @@ Indexes: "clstrpart_idx" btree (a) Number of partitions: 4 (Use \d+ to list them.) +-- Check that new children inherit clustered mark +ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; +CREATE TABLE clstrpart4 PARTITION OF clstrpart FOR VALUES FROM (30)TO(40); +\d clstrpart4 + Table "public.clstrpart4" + Column | Type | Collation | Nullable | Default +--------+---------+-----------+----------+--------- + a | integer | | | +Partition of: clstrpart FOR VALUES FROM (30) TO (40) +Indexes: + "clstrpart4_a_idx" btree (a) CLUSTER + -- Test CLUSTER with external tuplesorting create table clstr_4 as select * from tenk1; create index cluster_sort on clstr_4 (hundred, thousand, tenthous); diff --git a/src/test/regress/sql/cluster.sql b/src/test/regress/sql/cluster.sql index 3c8085c69e..22628e90ca 100644 --- a/src/test/regress/sql/cluster.sql +++ b/src/test/regress/sql/cluster.sql @@ -244,6 +244,10 @@ ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; CREATE TABLE clstrpart5 (LIKE clstrpart INCLUDING INDEXES); ALTER TABLE clstrpart ATTACH PARTITION clstrpart5 FOR VALUES FROM (40)TO(50); \d clstrpart +-- Check that new children inherit clustered mark +ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; +CREATE TABLE clstrpart4 PARTITION OF clstrpart FOR VALUES FROM (30)TO(40); +\d clstrpart4 -- Test CLUSTER with external tuplesorting -- 2.17.0 --AA9g+nFNFPYNJKiL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v7-0007-pg_dump-partitioned-index-depend-on-its-partition.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Making the ENUM operators LEAKPROOF @ 2026-07-01 22:33 Tom Lane <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2026-07-01 22:33 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: [email protected] Laurenz Albe <[email protected]> writes: > This is an attempt to get the operators from the "enum_ops" operator > class LEAKPROOF. I think we should reject this idea. Our standard for marking functions leakproof has always included a requirement that the amount of code involved be small enough that one can immediately confirm that there is no information leak. I don't think that enum_cmp() can meet that standard; the length of your argument already proves the point. The issue here is not really "can I convince myself that it's safe today?". It's more about "am I willing to bet that no future code change is going to unintentionally break the property?". The more code involved, the riskier that bet. I know that you are going to say "but text_cmp covers a lot of ground, including code (in libc or ICU) that isn't even ours". To my mind, we made an exception for text_cmp because the performance consequences of not making it leakproof were unacceptable. I do not think enum_cmp() can clear that bar either. FWIW, I do agree that marking enum_eq leakproof is safe. How many of the use-cases you are worried about would be satisfied with that? regards, tom lane ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-07-01 22:33 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-10-07 01:40 [PATCH v7 6/7] Preserve indisclustered on children of clustered, partitioned indexes Justin Pryzby <[email protected]> 2026-07-01 22:33 Re: Making the ENUM operators LEAKPROOF Tom Lane <[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