jasonyb
commented
3 months ago In the meantime, if you hit schema version mismatches (particularly for CREATE INDEX (CONCURRENTLY), which could use non-breaking schema version bumps after this change), check if you are using the extended query protocol, which doesn't allow transparent retry. If so, try to use the simple query protocol instead. Some drivers may not support customizing this.
For reference:
https://github.com/yugabyte/yugabyte-db/blob/550458d8f874d9363a1ccd6ee326dd9228b75e36/src/postgres/src/backend/tcop/postgres.c#L5593: simple query protocol: supports retry https://github.com/yugabyte/yugabyte-db/blob/550458d8f874d9363a1ccd6ee326dd9228b75e36/src/postgres/src/backend/tcop/postgres.c#L5668: extended query protocol:
/*
* TODO Cannot retry parse statements yet (without
* aborting the followup bind/execute.
*/
Jira Link: DB-6818
Description
The YSQL catalog version is a version number for YSQL system catalog tables. If a system table is modified and we want this modification to be propagated to all clients, the catalog version can be bumped, and clients that are on a prior version know to refresh their caches of these system tables.
Each user table also has a docdb schema version number. If a property of the table is changed, this version number may bump.
The catalog version bump is split into two types: breaking and nonbreaking. Breaking version bumps will cause ongoing queries/transactions to abort and force cache refresh. Nonbreaking version bumps will allow the ongoing query/transaction to finish and only at the next transaction boundary will it refresh the system table cache.
The docdb schema version bump only has one type: breaking.
Since nonbreaking version bumps are much less intrusive to ongoing DMLs, the docdb schema version bump should also support it. For example, docdb schema version is bumped when indexes are added, their read/write/delete permissions are changed, or they are deleted. These bumps could be nonbreaking since postgres has its own copy of index metadata that it uses, so the docdb metadata is not really used.
There have been alternate design ideas to solve the general issue. For example, there can be two parallel version numbers, one that YSQL cares about and breaks for and one that YSQL does not care about. So, unlike the breaking/nonbreaking version system where a breaking version bump really means that the breaking version is set to the same value as the bumped catalog version, the breaking version will bump up one and the nonbreaking version will stay the same.
Warning: Please confirm that this issue does not contain any sensitive information