Skip to content

Conversation

@jussisaurio
Copy link
Collaborator

No description provided.

motivation: try to catch bugs related to prepared statement reuse.
For repreparing prepared statements, we need to know what the required
version is, because the connection may already be on that version, but
the statement was compiled with an older one.
Simply checking `schema_version` is not enough to determine that schema
is up to date because of rolled-back schema updates. Generation is incremented
whenever the schema is changed, either forward or backward.
This may cause an unintended rollback of the transaction which
we don't want, instead we want the statement to be reprepared.
A prepared statement may have been compiled with a stale schema
version, but the connection itself might already be up to date. In this
case the connection doesn't need to clone db.schema.
As mentioned in a previous commit message, the schema version alone
is insufficient to determine that a statement was compiled with a stale
schema, because schema version `N` may refer to two different schemas
if one of them was rolled back.
this way we can remove the optionality of the field in
LimboError::SchemaUpdated and prepared statements are re-prepared
properly in the MVCC context too.
@nyrkio
Copy link

nyrkio bot commented Oct 23, 2025

Nyrkiö Report for Commit: ccb8b8d

No performance changes detected.

Remember that Nyrkiö results become more precise when more commits are merged. So please check back in a few days.

Nyrkiö

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant