Merge pull request #29782 from def-/pr-fix-issue-references

Fix two wrong issue references

doc/developer/design/20230223_stabilize_with_mutually_recursive.md

@@ -1,7 +1,7 @@
 - Feature name: Stabilize `WITH MUTUALLY RECURSIVE`
 - Associated:
   MaterializeInc/database-issues#3264 (first iteration),
-  MaterializeInc/database-issues#6172 (current epic).
+  MaterializeInc/database-issues#4922 (current epic).
 
 # Summary
 [Summary]: #summary
@@ -323,7 +323,7 @@ Once we have anonymized query logging, we can get some deper insights which woul
 
 ---
 
-Within the scope of MaterializeInc/database-issues#6172 we only provided the _basic case_ for most non-trivial transforms.
+Within the scope of MaterializeInc/database-issues#4922 we only provided the _basic case_ for most non-trivial transforms.
 Issues marked in [the above table](#mir-transformations) with _solution = basic_ represent opportunities for improvement.
 
 ---

doc/developer/design/20230330_recursion_limit.md

@@ -1,5 +1,5 @@
 - Feature name: (Recursion limit in WITH MUTUALLY RECURSIVE)
-- Associated: (Issues: [Stabilizing WMR (#17012)](https://github.com/MaterializeInc/database-issues/issues/6172), [#16800](https://github.com/MaterializeInc/database-issues/issues/4869), [#18362](https://github.com/MaterializeInc/database-issues/issues/5409), [#2392](https://github.com/MaterializeInc/database-issues/issues/835))
+- Associated: (Issues: [Stabilizing WMR (#7012)](https://github.com/MaterializeInc/database-issues/issues/7012), [#4869](https://github.com/MaterializeInc/database-issues/issues/4869), [#5409](https://github.com/MaterializeInc/database-issues/issues/5409), [#835](https://github.com/MaterializeInc/database-issues/issues/835))
 
 # Summary
 [summary]: #summary
@@ -14,8 +14,8 @@ The user can specify a limit using a SQL syntax extension at the level of WMR bl
 [motivation]: #motivation
 
 I can imagine 3 use cases, of which the 2. seems urgent to me:
-1. _Stopping divergent queries ([#16800](https://github.com/MaterializeInc/database-issues/issues/4869)):_ It is very easy to accidentally write a WMR query that runs forever (actually, until OOM in most cases, but that would often take a very long time). We used to have the additional problem that Ctrl+C (or dropping a materialized view or index) didn't cancel a dataflow ([#2392](https://github.com/MaterializeInc/database-issues/issues/835)), which made for quite an unpleasant user experience, as the user had to manually DROP the entire replica. However, proper dataflow cancellation for WMR queries has been [recently implemented](https://github.com/MaterializeInc/materialize/pull/18718), and therefore this use case of recursion limits is not so important anymore.
-2. _Debugging state between iterations ([#18362](https://github.com/MaterializeInc/database-issues/issues/5409)):_ WMR queries are not so obvious to write, so users often need to debug their queries during development. In such cases, it can be enlightening to inspect the intermediate states between iterations. If we had an option to limit the number of iterations, the user could just run the query repeatedly with successively larger limits. Multiple people expressed their wish for this feature, e.g., [here](https://materializeinc.slack.com/archives/C02CB7L4TCG/p1678266977745819?thread_ts=1678266846.169599&cid=C02CB7L4TCG).
+1. _Stopping divergent queries ([#4869](https://github.com/MaterializeInc/database-issues/issues/4869)):_ It is very easy to accidentally write a WMR query that runs forever (actually, until OOM in most cases, but that would often take a very long time). We used to have the additional problem that Ctrl+C (or dropping a materialized view or index) didn't cancel a dataflow ([#835](https://github.com/MaterializeInc/database-issues/issues/835)), which made for quite an unpleasant user experience, as the user had to manually DROP the entire replica. However, proper dataflow cancellation for WMR queries has been [recently implemented](https://github.com/MaterializeInc/materialize/pull/18718), and therefore this use case of recursion limits is not so important anymore.
+2. _Debugging state between iterations ([#5409](https://github.com/MaterializeInc/database-issues/issues/5409)):_ WMR queries are not so obvious to write, so users often need to debug their queries during development. In such cases, it can be enlightening to inspect the intermediate states between iterations. If we had an option to limit the number of iterations, the user could just run the query repeatedly with successively larger limits. Multiple people expressed their wish for this feature, e.g., [here](https://materializeinc.slack.com/archives/C02CB7L4TCG/p1678266977745819?thread_ts=1678266846.169599&cid=C02CB7L4TCG).
 3. _Algorithms requiring a fixed number of iterations:_ Some algorithms are unintuitive to express as a loop running until a fixpoint (or reaching a fixpoint can't be ensured), and instead need a loop that runs a specific number of times. Note that in the above two use cases, we don't expect to run into the limit in production under normal operation, but in this use case a limit will be part of the logic of production queries.
 
 # Explanation

misc/python/materialize/postgres_consistency/ignore_filter/pg_inconsistency_ignore_filter.py

@@ -824,7 +824,7 @@ def matches_round_function(expression: Expression) -> bool:
             return YesIgnore("database-issues#8281: infinity to decimal")
 
         if "invalid regular expression flag: n" in mz_error_msg:
-            return YesIgnore("database-issues#9725: regex n flag")
+            return YesIgnore("database-issues#8409: regex n flag")
 
         if "aggregate functions are not allowed in table function" in mz_error_msg:
             return YesIgnore(
@@ -1118,7 +1118,7 @@ def _shall_ignore_pg_typeof_content_mismatch(
             ),
             True,
         ):
-            return YesIgnore("database-issues#9721: return type of floor and ceil")
+            return YesIgnore("database-issues#8407: return type of floor and ceil")
 
         if query_template.matches_specific_select_or_filter_expression(
             col_index,

src/compute/src/render/reduce.rs

@@ -409,7 +409,7 @@ where
 
                         // If we did not have enough values to stitch together, then we do not
                         // generate an output row. Not outputting here corresponds to the semantics
-                        // of an equi-join on the key, similarly to the proposal in PR database-issues#6173.
+                        // of an equi-join on the key, similarly to the proposal in PR materialize#17013.
                         //
                         // Note that we also do not want to have anything left over to stich. If we
                         // do, then we also have an error, reported elsewhere, and would violate

test/cluster/mzcompose.py

@@ -881,7 +881,7 @@ def workflow_test_github_17510(c: Composition) -> None:
             ! SELECT * FROM constant_sums;
             contains:constant folding encountered reduce on collection with non-positive multiplicities
 
-            # The following statement verifies that the behavior introduced in PR database-issues#6122
+            # The following statement verifies that the behavior introduced in PR materialize#6122
             # is now rectified, i.e., instead of wrapping to a negative number, we produce
             # an error upon seeing invalid multiplicities.
             ! SELECT SUM(data8) FROM data;

test/testdrive/replica-targeting.td

@@ -75,7 +75,7 @@ $ set-regex match=\d{13} replacement=<TIMESTAMP>
 > COMMIT
 
 # Test that replica-targeted subscribes work when the subscribed collection
-# advances to the empty frontier. Regression test for database-issues#8711.
+# advances to the empty frontier. Regression test for database-issues#7457.
 
 > DROP CLUSTER test CASCADE
 > CREATE CLUSTER test SIZE '4-4', REPLICATION FACTOR 4