-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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.
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
sql: propagate default int size to remote nodes #50035
Conversation
A while ago we added support of `DEFAULT_INT_SIZE` which can be set either to 8 (default) or 4 bytes. So far that setting has been used to influence how we parse the "naked" INT in the query from the client. However, there is one other place where we're performing the parsing: during expression deserialization on the remote nodes. Previously, the setting hasn't been propagated to remote nodes, so we might have interpreted it incorrectly. This commit addresses that. Release note: None
Together with @jordanlewis we found this when looked into some test failures while I was working on #49891. However, now I believe that this propagation is actually unnecessary - my current understanding is that we see "naked" |
I think that it's useful for consistency, so that there's no discrepancy between local and remote execution.
Also we have a pg builtin function that retrieves session variables, we may want to keep the option to eventually run them on any node not just the gateway?
--
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.
|
Hm, did you mean that we should propagate an update to |
I mean what this PR does. I was surprised it doesn't already actually; I thought the entire SessionData struct was propagated as-is. Maybe it could be an idea to make SessionData a protobuf and have the same struct used directly by the executor and serialized with the distsql plans. This way it'd always be up to date. |
It's an interesting idea. I think there might be a possible downside to it: it seems that many packages import Anyway, I'll bring this idea up during our weekly meeting tomorrow. |
@yuzefovich to create an issue |
I think this is still relevant, especially in light of the recent realization that we get internal executors spawned on distsql proecssors. Casts executed remotely need to know about the int size!! |
#55569 does more than this PR, so closing. |
A while ago we added support of
DEFAULT_INT_SIZE
which can be seteither to 8 (default) or 4 bytes. So far that setting has been used to
influence how we parse the "naked" INT in the query from the client.
However, there is one other place where we're performing the parsing:
during expression deserialization on the remote nodes. Previously, the
setting hasn't been propagated to remote nodes, so we might have
interpreted it incorrectly. This commit addresses that.
Release note: None