Add latest changes from gitlab-org/gitlab@13-9-stable-eev13.9.0-rc42

3 files changed, 10 insertions, 4 deletions

diff --git a/doc/development/database/database_reviewer_guidelines.md b/doc/development/database/database_reviewer_guidelines.md
index 26083183d6d..a242a3d5fd0 100644
--- a/doc/development/database/database_reviewer_guidelines.md
+++ b/doc/development/database/database_reviewer_guidelines.md
@@ -50,17 +50,17 @@ European/US and APAC friendly hours. You can join the office hours call and brin
 that require a more in-depth discussion between the database reviewers and maintainers:
 
 - [Database Office Hours Agenda](https://docs.google.com/document/d/1wgfmVL30F8SdMg-9yY6Y8djPSxWNvKmhR5XmsvYX1EI/edit).
-- [Youtube playlist with past recordings](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp-kqXeiF7fF7cFYaKtdqXM).
+- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [YouTube playlist with past recordings](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp-kqXeiF7fF7cFYaKtdqXM).
 
 You should also join the [#database-labs](../understanding_explain_plans.md#database-lab)
-Slack channel and get familiar with how to use Joe, the slackbot that provides developers
+Slack channel and get familiar with how to use Joe, the Slackbot that provides developers
 with their own clone of the production database.
 
 Understanding and efficiently using `EXPLAIN` plans is at the core of the database review process.
 The following guides provide a quick introduction and links to follow on more advanced topics:
 
 - Guide on [understanding EXPLAIN plans](../understanding_explain_plans.md).
-- [Explaining the unexplainable series in depesz](https://www.depesz.com/tag/unexplainable/).
+- [Explaining the unexplainable series in `depesz`](https://www.depesz.com/tag/unexplainable/).
 
 Finally, you can find various guides in the [Database guides](index.md) page that cover more specific
 topics and use cases. The most frequently required during database reviewing are the following:
diff --git a/doc/development/database/strings_and_the_text_data_type.md b/doc/development/database/strings_and_the_text_data_type.md
index 33a0fd2ebb7..f338520c6ca 100644
--- a/doc/development/database/strings_and_the_text_data_type.md
+++ b/doc/development/database/strings_and_the_text_data_type.md
@@ -34,6 +34,12 @@ but only for updating the declaration of the columns. We can then validate it at
 `VALIDATE CONSTRAINT`, which requires only a `SHARE UPDATE EXCLUSIVE LOCK` (only conflicts with other
 validations and index creation while it allows reads and writes).
 
+### Exceptions
+
+Text columns used by `attr_encrypted` are not required to have a limit, because the length of the
+text after encryption may be longer than the text itself. Instead, you can use an Active Record
+length validation on the attribute.
+
 ## Create a new table with text columns
 
 When adding a new table, the limits for all text columns should be added in the same migration as
diff --git a/doc/development/database/table_partitioning.md b/doc/development/database/table_partitioning.md
index 358b9bb42b0..207d5a733ce 100644
--- a/doc/development/database/table_partitioning.md
+++ b/doc/development/database/table_partitioning.md
@@ -60,7 +60,7 @@ was the first table to be partitioned in the application database
 (scheduled for deployment with the GitLab 13.5 release). This
 table tracks audit entries of security events that happen in the
 application. In almost all cases, users want to see audit activity that
-occurs in a certain timeframe. As a result, date-range partitioning
+occurs in a certain time frame. As a result, date-range partitioning
 was a natural fit for how the data would be accessed.
 
 To look at this in more detail, imagine a simplified `audit_events` schema: