Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unary Complement execution has different results when the parameters are different #74493

Closed
Heoric opened this issue Jan 6, 2022 · 2 comments · Fixed by #76943
Closed

Unary Complement execution has different results when the parameters are different #74493

Heoric opened this issue Jan 6, 2022 · 2 comments · Fixed by #76943
Assignees
@ecwall
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. O-community Originated from the community T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@Heoric
Copy link

Heoric commented Jan 6, 2022 •
edited by cockroach-jira-scripts
Loading 

root@localhost:26257/defaultdb> select ~'1';
ERROR: unsupported unary operator: ~ <string>
SQLSTATE: 22023
root@localhost:26257/defaultdb> select ~'2';
  ?column?
------------
        -3
(1 row)

Time: 1ms total (execution 1ms / network 0ms)

Epic CRDB-8948

Jira issue: CRDB-12112
@Heoric Heoric added the C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. label Jan 6, 2022
@blathers-crl
Copy link

blathers-crl bot commented Jan 6, 2022

Hello, I am Blathers. I am here to help you get the issue triaged.

It looks like you have not filled out the issue in the format of any of our templates. To best assist you, we advise you to use one of these templates.

I was unable to automatically find someone to ping.

If we have not gotten back to your issue within a few business days, you can try the following:

  • Join our community slack channel and ask on #cockroachdb.
  • Try find someone from here if you know they worked closely on the area and CC them.

🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan.

@blathers-crl blathers-crl bot added O-community Originated from the community X-blathers-untriaged blathers was unable to find an owner labels Jan 6, 2022
@blathers-crl blathers-crl bot added the T-sql-queries SQL Queries Team label Jan 6, 2022
@rafiss rafiss removed the X-blathers-untriaged blathers was unable to find an owner label Jan 6, 2022
@blathers-crl blathers-crl bot added the T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) label Jan 6, 2022
@rafiss
Copy link
Collaborator

rafiss commented Feb 7, 2022

It seems like select ~'2'; does not work in Postgres, so from a compatibility perspective, we might consider disallowing that in CockroachDB as well.

First we should investigate and determine why the behavior is different in the two examples.

@exalate-issue-sync exalate-issue-sync bot removed the T-sql-queries SQL Queries Team label Feb 22, 2022
@ecwall ecwall mentioned this issue Feb 23, 2022
Merged
craig bot pushed a commit that referenced this issue Mar 2, 2022
@arulajmani @ajstorm
@ecwall @sumeerbhola
Merge #75285 #76929 #76943 #77064 #77245
1cc1725 
75285: spanconfig: introduce the ProtectedTSReader interface  r=adityamaru,nvanbenschoten,ajwerner a=arulajmani

See individual commits for details. 

Release justification: low risk, high benefit changes to existing
functionality.

76929: settings: Add syntax for cluster settings r=raduberinde,rafiss a=ajstorm

Before this commit, there was no syntax to SET or SHOW cluster settings which
exist for a given tenant. This commit adds the following syntax:

* ALTER TENANT <id> SET CLUSTER SETTING <setting> = <value>
* ALTER TENANT ALL SET CLUSTER SETTING <setting> = <value>
* ALTER TENANT <id> RESET CLUSTER SETTING <setting>
* ALTER TENANT ALL RESET CLUSTER SETTING <setting>
* SHOW CLUSTER SETTING <setting> FOR TENANT <id>
* SHOW [ALL] CLUSTER SETTINGS FOR TENANT <id>

Note that the syntax is added but the underlying commands are currently
unimplemented. The implementation of these commands will come with a subsequent
commit.

Release note (sql change): Added syntax for modifying cluster settings at the
tenant level.

Informs: #73857.

76943: Unary Complement execution has different results when the parameters are different r=otan a=ecwall

fixes #74493

Release note (sql change): Return ambiguous unary operator error for ambiguous input
like ~'1' which can be interpreted as an integer (resulting in -2) or a bit string
(resulting in 0).

Release justification: Improves a confusing error message saying that an operator is
invalid instead of ambiguous.

77064: spanconfigkvsubscriber,kvserver: fix KVSubscriber bug r=arulajmani a=arulajmani

We had a bug in the KVSubscriber where we were invoking a copy of the
handler instead of the handler stored. This meant that we'd never treat
handlers as "initialized". As a result, we would always invoke them with
the everything span, and as a result, visit all replicas on the stores
in reaction to span config updates. See datadriven test diffs for an
illustration.

Fixing the above lead to unearthing an interesting bug in how we were
deciding to enqueue replicas in the split queue. Previously, if we
received  a span config update that implied a split and the update
corresponded to the right-hand side post split, we would skip enqueuing
the replica in the split queue. The assumption was that we'd get an
update corresponding to the LHS of the split for the same replica
and that update would enqueue the replica. This doesn't always hold true
though. For example, consider the case when a new table is created and
must be split from its (left) adjacent table's range. This only results
in a single update, corresponding to the new table's span, which is the
right-hand side post split.

This patch moves to nudging the split queue for all updates, not just
left-hand side updates, for the reason above.

Release note: None
Release justification: bug fixes in new functionality

77245: kvserver: fix race in durability callback queueing in raftLogTruncator r=erikgrinaker a=sumeerbhola

The existing code admitted the following interleaving between
thread-1, running the async raft log truncation, and thread-2
which is running a new durabilityAdvancedCallback.

thread-1: executes queued := t.mu.queuedDurabilityCB and
 sees queued is false
thread-2: sees t.mu.runningTruncation is true and sets
 t.mu.queuedDurabilityCB = true
thread-1: Sets t.mu.runningTruncation = false and returns

Now the queued callback will never run. This can happen in tests
that wait for truncation before doing the next truncation step,
because they will stop waiting once the truncation is observed
on a Replica, which happens before any of the steps listed above
for thread-1.

Fixes #77046

Release justification: Bug fix

Release note: None

Co-authored-by: arulajmani <[email protected]>
Co-authored-by: Adam Storm <[email protected]>
Co-authored-by: Evan Wall <[email protected]>
Co-authored-by: sumeerbhola <[email protected]>
@craig craig bot closed this as completed in 5eba198 Mar 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ecwall ecwall

Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. O-community Originated from the community T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Unary Complement execution has different results when the parameters are different
3 participants
@rafiss @ecwall @Heoric