SQL Queries v25.4 known limitations #20811
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,7 @@ | ||
| - When columns are [indexed]({% link {{ page.version.version }}/indexes.md %}), a subset of data from the indexed columns may appear in [meta ranges]({% link {{ page.version.version }}/architecture/distribution-layer.md %}#meta-ranges) or other system tables. CockroachDB synchronizes these system ranges and system tables across nodes. This synchronization does not respect any multi-region settings applied via either the [multi-region SQL statements]({% link {{ page.version.version }}/multiregion-overview.md %}), or the low-level [zone configs]({% link {{ page.version.version }}/configure-replication-zones.md %}) mechanism. | ||
| - [Zone configs]({% link {{ page.version.version }}/configure-replication-zones.md %}) can be used for data placement but these features were historically built for performance, not for domiciling. The replication system's top priority is to prevent the loss of data and it may override the zone configurations if necessary to ensure data durability. For more information, see [Replication Controls]({% link {{ page.version.version }}/configure-replication-zones.md %}#types-of-constraints). | ||
| - If your [log files]({% link {{ page.version.version }}/logging-overview.md %}) are kept in the region where they were generated, there is some cross-region leakage (like the system tables described previously), but the majority of user data that makes it into the logs is going to be homed in that region. If that's not strong enough, you can use the [log redaction functionality]({% link {{ page.version.version }}/configure-logs.md %}#redact-logs) to strip all raw data from the logs. You can also limit your log retention entirely. | ||
| - If you start a node with a [`--locality`]({% link {{ page.version.version }}/cockroach-start.md %}#locality) flag that says the node is in region _A_, but the node is actually running in some region _B_, data domiciling based on the inferred node placement will not work. A CockroachDB node only knows its locality based on the text supplied to the `--locality` flag; it can not ensure that it is actually running in that physical location. | ||
| - When using the `infer_rbr_region_col_using_constraint` option, inserting rows with `DEFAULT` for the region column uses the database's primary region instead of inferring the region from the parent table via foreign-key constraint. [#150783](https://github.com/cockroachdb/cockroach/issues/150783) | ||
| - {% include {{page.version.version}}/known-limitations/secondary-regions-with-regional-by-row-tables.md %} | ||
| - {% include {{ page.version.version }}/known-limitations/enforce-home-region-limitations.md %} |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| `LIKE` queries with an `ESCAPE` clause cannot use index acceleration, which can result in significantly slower performance compared to standard `LIKE` queries. [#30192](https://github.com/cockroachdb/cockroach/issues/30192) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1 @@ | ||
| [Secondary regions]({% link {{ page.version.version }}/multiregion-overview.md %}#secondary-regions) are not compatible with databases containing [`REGIONAL BY ROW`]({% link {{ page.version.version }}/table-localities.md %}#regional-by-row-tables) tables. CockroachDB does not prevent you from defining secondary regions on databases with regional by row tables, but the interaction of these features is not supported. Therefore, Cockroach Labs recommends that you avoid defining secondary regions on databases that use regional by row table configurations. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,4 @@ | ||
| {% if page.name != "known-limitations.md" # New limitations in v24.2 %} | ||
| {% endif %} | ||
| - `COMMIT` and `ROLLBACK` statements are not supported within nested procedures. [#122266](https://github.com/cockroachdb/cockroach/issues/122266) | ||
| - Pausable portals are not supported with `CALL` statements for stored procedures. [#151529](https://github.com/cockroachdb/cockroach/issues/151529) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,7 @@ | ||
| - A [trigger function]({% link {{ page.version.version }}/triggers.md %}#trigger-function) that is used in an existing trigger cannot be replaced with `CREATE OR REPLACE` syntax. To use `CREATE OR REPLACE`, first [drop any triggers]({% link {{ page.version.version }}/drop-trigger.md %}) that are using the function. [#134555](https://github.com/cockroachdb/cockroach/issues/134555) | ||
| - Hidden columns are not visible to triggers. [#133331](https://github.com/cockroachdb/cockroach/issues/133331) | ||
| - The `REFERENCING` clause for `CREATE TRIGGER` is not supported. [#135655](https://github.com/cockroachdb/cockroach/issues/135655) | ||
| - CockroachDB uses one-based indexing for the `TG_ARGV` array to maintain consistency with its array indexing system. This differs from PostgreSQL, where `TG_ARGV` uses zero-based indexing, unlike other PostgreSQL arrays. Trigger functions that reference `TG_ARGV` need to be adjusted when migrating from PostgreSQL. [#135311](https://github.com/cockroachdb/cockroach/issues/135311) | ||
| - `UPDATE` triggers with a column list (using `UPDATE OF column_name` syntax) are not supported. [#135656](https://github.com/cockroachdb/cockroach/issues/135656) | ||
| - Statement-level triggers for `TRUNCATE` events are not supported. [#135657](https://github.com/cockroachdb/cockroach/issues/135657) | ||
| - {% include {{ page.version.version }}/known-limitations/drop-trigger-limitations.md %} |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| - The `security_invoker` attribute for views is not supported. Views always use the view definer's privileges when checking permissions. [#138918](https://github.com/cockroachdb/cockroach/issues/138918) |
|
Contributor
There was a problem hiding this comment. I don't know how much this matters, but this introduces a second "Known limitations" header to the /docs/dev/views page, which slightly messes with the ability to navigate to the bottom one via the ToC.
Contributor
Author
There was a problem hiding this comment. I didn't realize! Fixed.
Contributor
Author
There was a problem hiding this comment. On your other point, thank you for raising it. This is admittedly clunky, and is an outcome of how the includes are set up. In the v25.3 section, all KLs for a given topic are contained in the include for that topic. That include file is embedded on the respective feature pages (like for UDFs and Stored Procedures), where all the relevant KLs can also be viewed. Because of how the main Known Limitations page is set up, we also have the newly identified KLs in the top section. The "correct" way to do this would be to have the lines appear only 1) in the top section of new KLs, 2) on the various feature pages, outside the KL includes (so that they aren't missing there). I felt this would add too much burden for the next version, because we'd have to take the "new" lines and distribute them among the appropriate include files. The way it is now, we just have to clear everything in the "new" section when we update this page for 26.1. The headings on this page may also be misleading: "New limitations" means "newly identified limitations"; "Limitations from v24.3 and earlier" means "limitations we already knew about when these versions were released". I don't think most (if any) of these would be considered "newly introduced" limitations unless the feature itself were new, in which case it wouldn't be in the "earlier" section anyway. Perhaps we should adjust the headings. In any case, it means it's not a total contradiction to have them in two places.
Contributor
There was a problem hiding this comment. Just trying to get my head around this... I'm a little confused because I don't see this same duplication in previous versions when I check, for example, https://www.cockroachlabs.com/docs/v25.3/known-limitations I suppose in a ideal case you could have two separate include files, one for old limitations and one for new limitations, and you separate them on the main known limitations page and join them up on the feature page, but I understand that that might be too much overhead and/or might be out of scope for this PR. None of this is a big deal I'm just curious and dogged haha.
Contributor
Author
There was a problem hiding this comment. It seems the reason the 25.3 "new" limitations aren't duplicated is because they were only placed in the "new" section and not in any of the feature sections. In this PR, I moved them all to existing & new subheadings on the KLs page that I thought were appropriate. Also, the use of includes for KLs is intended to enable them to be embedded in multiple docs. The way I do it currently, all the KLs for (e.g.) stored procedures are in a In contrast, v25.3 have common include files for "geospatial" or "rls" (row-level security), so those are one-off includes. It also doesn't seem useful to have the KLs within includes, since they're only being used in one place. This system is still relatively new and could use another look. I'm open to ideas. In the meantime, do you think the temporary duplication here is acceptable, or should I remove the dupes in the v25.3 section and put them back inside the includes for next version (I guess I did do that work this time, too)?
Contributor
There was a problem hiding this comment. If we feel the distinction is worth making (this is a newly-identified limitation vs. this is a limitation that we'd already identified in previous versions) then I think we should probably avoid the duplication, as it's sort of confusing. Having separate include files for old and new limitations could work for that, but also maybe there's a cleverer solution? Then again, I don't think the duplication will have an effect beyond mild confusion for anyone (possibly no one) who notices it. It's clear in any case that the limitation still affects v25.4, so who cares when it was introduced. Unless... possibly it matters to someone who's considering upgrading to the newest version, and that known limitation is relevant to that decision. Maybe then it should be very clear that the limitation is genuinely new. But maybe that's an edge case. I guess long term I'm anti-duplication but maybe a rethink of the include file situation is a separate PR?
Contributor
Author
There was a problem hiding this comment. So ... I completely forgot that I had already solved this problem when I came up with this system. Some of the include files have a conditional block for new KLs that prevents them from appearing when they're on the Known Limitations page (where they will already be at the top). For the next version, you just move them outside that conditional block. This should be fixed now!
Contributor
There was a problem hiding this comment. ah amazing, elegant solution |
Uh oh!
There was an error while loading. Please reload this page.