[pull] master from mattermost:master#699
Merged
Merged
Conversation
#36350) * [MM-68588] Add notice in System Console when policy has mixed channel types When a membership policy in the System Console policy editor has both public and private channels assigned, the implications differ by type: private channels restrict access while public channels are advisory. Add an informational SectionNotice below the assigned-channels list explaining the distinction so admins understand the behavior before saving. The notice only appears when the effective channel set (saved - removed + added) contains at least one channel of each type. Refactored the public/private counting that was previously inlined in the confirmation modal block into a useMemo so the same calculation drives both the new notice and the existing confirmation modal. Made-with: Cursor * Add mixed channel notice to team policy editor Co-authored-by: Ibrahim Serdar Acikgoz <isacikgoz@users.noreply.github.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Ibrahim Serdar Acikgoz <isacikgoz@users.noreply.github.com>
…ture flag (#36488) The two shared DM/GM subtests in TestCreatePost rely on FeatureFlags.EnableSharedChannelsDMs being false, but the config store reapplies MM_FEATUREFLAGS_* env overrides on every Set, so an UpdateConfig pin gets clobbered. Use t.Setenv to force the flag false for the duration of each subtest, and drop the parent's mainHelper.Parallel(t) so Go's "no Setenv under a parallel ancestor" rule is satisfied. Sibling subtests still parallelize via their own mainHelper.Parallel(t) calls.
…nnelid (#36506) * MM-68722 - Set higher statistics target on posts.rootid and posts.channelid The default PostgreSQL column statistics target (100) is too coarse for posts.rootid: most rows have an empty rootid and the remainder is a long tail of distinct thread IDs, so the planner cannot accurately estimate selectivity for a specific non-empty rootid. As a result, queries like the per-thread MAX(createat) issued from updateThreadsFromPosts get planned to scan idx_posts_create_at backward and filter by rootid, scanning tens of millions of rows per call instead of using the idx_posts_root_id_delete_at index. This was observed during a large DM import where 16 workers were each stuck on the same query for 20 to 70 seconds, dropping import throughput from a few thousand posts per minute to ~155 per minute. Raising the statistics target to 5000 on rootid (and on channelid for the same reason) lets ANALYZE record enough most-common-values that the planner correctly recognizes specific non-empty values as highly selective and picks the right index. Verified locally: post-fix the query runs in 0.058 ms with 11 buffer hits, vs 20725 ms with 25.8M buffer hits before. This is a metadata-only change. ALTER TABLE ... SET STATISTICS takes a SHARE UPDATE EXCLUSIVE lock and does not block concurrent DML. * MM-68722 - Run ANALYZE in migration so new statistics target takes effect immediately ALTER TABLE ... SET STATISTICS only changes the target; the planner keeps using the existing sample in pg_statistic until ANALYZE runs. On a busy Posts table autoanalyze fires after ~10 percent of rows change, and on a quiet site it may not fire at all before the operator runs the import that motivates this change. Running ANALYZE in the migration ensures the new sample is collected at deploy time rather than at an indeterminate later point. Scoped to (rootid, channelid) since those are the only columns whose statistics target changed. Both are gathered in a single table scan. ANALYZE takes SHARE UPDATE EXCLUSIVE and does not block DML. No corresponding change in the down migration: resetting the target to -1 leaves the existing samples valid for continued planner use, so no rollback-time ANALYZE is needed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )