public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v7 4/7] Invalidate parent indexes 2+ messages / 2 participants [nested] [flat]
* [PATCH v7 4/7] Invalidate parent indexes @ 2020-11-06 00:58 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2020-11-06 00:58 UTC (permalink / raw) --- src/backend/commands/cluster.c | 21 +++++++++++++++++++++ src/test/regress/expected/cluster.out | 26 ++++++++++++++++++++++++++ src/test/regress/sql/cluster.sql | 8 ++++++++ 3 files changed, 55 insertions(+) diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c index 78c2c2ba72..05c84e5582 100644 --- a/src/backend/commands/cluster.c +++ b/src/backend/commands/cluster.c @@ -594,6 +594,27 @@ mark_index_clustered(Relation rel, Oid indexOid, bool is_internal) } list_free(inh); + /* + * Set parent of all indexes as unclustered when a rel is unclustered; and, + * when an index is clustered, set parents of all /other/ indexes as + * unclustered. + */ + indexes = RelationGetIndexList(rel); + foreach (lc, indexes) + { + Oid thisIndexOid = lfirst_oid(lc); + + if (thisIndexOid == indexOid) + continue; + + while (get_rel_relispartition(thisIndexOid)) + { + thisIndexOid = get_partition_parent(thisIndexOid); + set_indisclustered(thisIndexOid, false, pg_index); + } + } + list_free(indexes); + table_close(pg_index, RowExclusiveLock); } diff --git a/src/test/regress/expected/cluster.out b/src/test/regress/expected/cluster.out index 1d436dfaae..6cba3cc4f9 100644 --- a/src/test/regress/expected/cluster.out +++ b/src/test/regress/expected/cluster.out @@ -541,6 +541,32 @@ Indexes: "clstrpart1_idx_2" btree (a) CLUSTER Number of partitions: 2 (Use \d+ to list them.) +-- Check that the parent index is marked not clustered after clustering a partition on a different index: +ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; +CLUSTER clstrpart1 USING clstrpart1_idx_2; +\d clstrpart + Partitioned table "public.clstrpart" + Column | Type | Collation | Nullable | Default +--------+---------+-----------+----------+--------- + a | integer | | | +Partition key: RANGE (a) +Indexes: + "clstrpart_idx" btree (a) +Number of partitions: 3 (Use \d+ to list them.) + +-- Check that the parent index is marked not clustered after setting a partition not clustered: +ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; +ALTER TABLE clstrpart1 SET WITHOUT CLUSTER; +\d clstrpart + Partitioned table "public.clstrpart" + Column | Type | Collation | Nullable | Default +--------+---------+-----------+----------+--------- + a | integer | | | +Partition key: RANGE (a) +Indexes: + "clstrpart_idx" btree (a) +Number of partitions: 3 (Use \d+ to list them.) + -- 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 0ded2be1ca..a1d132f288 100644 --- a/src/test/regress/sql/cluster.sql +++ b/src/test/regress/sql/cluster.sql @@ -231,6 +231,14 @@ CREATE INDEX clstrpart1_idx_2 ON clstrpart1(a); ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; ALTER TABLE clstrpart1 CLUSTER ON clstrpart1_idx_2; \d clstrpart1 +-- Check that the parent index is marked not clustered after clustering a partition on a different index: +ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; +CLUSTER clstrpart1 USING clstrpart1_idx_2; +\d clstrpart +-- Check that the parent index is marked not clustered after setting a partition not clustered: +ALTER TABLE clstrpart CLUSTER ON clstrpart_idx; +ALTER TABLE clstrpart1 SET WITHOUT CLUSTER; +\d clstrpart -- Test CLUSTER with external tuplesorting -- 2.17.0 --AA9g+nFNFPYNJKiL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v7-0005-Invalidate-parent-index-cluster-on-attach.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Incorrect handling of OOM in WAL replay leading to data loss @ 2023-08-08 05:52 Michael Paquier <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Michael Paquier @ 2023-08-08 05:52 UTC (permalink / raw) To: Jeff Davis <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; Postgres hackers <[email protected]>; [email protected]; Nathan Bossart <[email protected]>; Masahiko Sawada <[email protected]> On Tue, Aug 01, 2023 at 04:39:54PM -0700, Jeff Davis wrote: > On Tue, 2023-08-01 at 16:14 +0300, Aleksander Alekseev wrote: > > Probably I'm missing something, but if memory allocation is required > > during WAL replay and it fails, wouldn't it be a better solution to > > log the error and terminate the DBMS immediately? > > We need to differentiate between: > > 1. No valid record exists and it must be the end of WAL; LOG and start > up. > > 2. A valid record exists and we are unable to process it (e.g. due to > OOM); PANIC. Yes, still there is a bit more to it. The origin of the introduction to palloc(MCXT_ALLOC_NO_OOM) partially comes from this thread, that has reported a problem where we switched from malloc() to palloc() when xlogreader.c got introduced: https://www.postgresql.org/message-id/[email protected]... And the malloc() behavior when replaying WAL records is even older than that. At the end, we want to be able to give more options to anybody looking at WAL records, and let them take decisions based on the error reached and the state of the system. For example, it does not make much sense to fail hard on OOM if replaying records when in standby mode because we can just loop again. The same can actually be said when in crash recovery. On OOM, the startup process considers that we have an invalid record now, which is incorrect. We could fail hard and FATAL to replay again (sounds like the natural option), or we could loop over the record that failed its allocation, repeating things. In any case, we need to give more information back to the system so as it can take better decisions on what it should do. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../ZNHYKkKpkJ%[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-08-08 05:52 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-06 00:58 [PATCH v7 4/7] Invalidate parent indexes Justin Pryzby <[email protected]> 2023-08-08 05:52 Re: Incorrect handling of OOM in WAL replay leading to data loss Michael Paquier <[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