-
Notifications
You must be signed in to change notification settings - Fork 916
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
[Bug]: Wrong result returned after compressing column, with alter table, new column with default value #7714
Labels
Comments
Potentially related issue: when I alter-added the new column I set the default value to 42, and then I altered it to 99 and 33 at last. Somehow the 42 came back after compression.
|
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 6, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. A utility function that allows us to check if a value is missing from a tuple is added, also for supporting the future PR's upgrade script.
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 6, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. A utility function that allows us to check if a value is missing from a tuple is added, also for supporting the future PR's upgrade script.
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 6, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR.
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 6, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR.
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 6, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. Fixes: timescale#7714
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 6, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. Fixes timescale#7714
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 7, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. Fixes timescale#7714
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 7, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. Fixes timescale#7714
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 7, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. Fixes timescale#7714
dbeck
added a commit
to dbeck/timescaledb
that referenced
this issue
Mar 8, 2025
This fixes bug timescale#7714 where adding a column with a default value (jargon: missing value) and a compressed batch with all nulls created an ambiguity. In the all null cases the compressed block was stored as a NULL value. With this change, I introduce a new special compression type, the 'NULL' compression which is a single byte place holder for an 'all-null' compressed block. This allows us to distinguish between the missing value vs the all-null values. Please note that the wrong results impacted existing tests so I updated the expected results, as well as I added reference queries before compression to prove the updated values were wrong before. A new debug only GUC was added for testing a future upgrade script, which will arrive as a separate PR. Fixes timescale#7714
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What type of bug is this?
Incorrect result
What subsystems and features are affected?
Compression
What happened?
I'm creating this bug after Sven Klemm found the issue and Alexander Kuzmenkov provided a further repro.
In the two repros we:
After these steps we expect the compressed table to return the null value, but instead it returns the default value.
TimescaleDB version affected
2.18.0
PostgreSQL version used
16.6
What operating system did you use?
Ubuntu 22.04 x86
What installation method did you use?
Source
What platform did you run on?
On prem/Self-hosted
Relevant log output and stack trace
How can we reproduce the bug?
The text was updated successfully, but these errors were encountered: