[
https://issues.apache.org/jira/browse/IGNITE-27460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-27460:
---------------------------------------
Description:
For implicit transactions with 1PC operations, we start a transaction at moment
B, then we validate that the schema has not changed yet at some moment V > B,
then we write the new row version (directly, without the write intent phase)
using C (> B) as commit timestamp.
But we never validate schema change validity between B and C. So it could
happen that an incomplete schema change happens between B and C, but we would
not notice this and still write the row version with commitTs pointing at the
schema that is not forward-compatible to the schema in which the data of that
row version is actually written (as this schema corresponds to B).
This was probably accidentally broken in IGNITE-23304.
For explicit transactions, correctness of the same schema validation has to be
checked as well.
was:
For implicit transactions with 1PC operations, we start a transaction at moment
B, then we validate that the schema has not changed yet at some moment V > B,
then we write the new row version (directly, without the write intent phase)
using C (> B) as commit timestamp.
But we never validate schema change validity between B and C. So it could
happen that an incomplete schema change happens between B and C, but we would
not notice this and still write the row version with commitTs pointing at the
schema that is not forward-compatible to the schema in which the data of that
row version is actually written (as this schema corresponds to B).
> Schema change consistency is broken
> -----------------------------------
>
> Key: IGNITE-27460
> URL: https://issues.apache.org/jira/browse/IGNITE-27460
> Project: Ignite
> Issue Type: Bug
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> For implicit transactions with 1PC operations, we start a transaction at
> moment B, then we validate that the schema has not changed yet at some moment
> V > B, then we write the new row version (directly, without the write intent
> phase) using C (> B) as commit timestamp.
> But we never validate schema change validity between B and C. So it could
> happen that an incomplete schema change happens between B and C, but we would
> not notice this and still write the row version with commitTs pointing at the
> schema that is not forward-compatible to the schema in which the data of that
> row version is actually written (as this schema corresponds to B).
> This was probably accidentally broken in IGNITE-23304.
> For explicit transactions, correctness of the same schema validation has to
> be checked as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
