-
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]: license errors in v2.18.1 while autovacuuming chunks with hypercore access method #7702
Comments
@jflambert Thanks for the bug report. I can reproduce the issue here with a different setup by starting a backend and running a simple query with a "default" crossmodule function call. The issue occurs because the license check is done quite early but the module load (and shared library load) for the process is done quite late (in Working on a fix, but a workaround is to add the libraries for your version to
I used this in my reproduction, and it seems to work. |
This works! Hopefully 2.18.2 isn't too far off. I confirm the errors are gone, and the vacuum (both manual and automatic) seems to work as expected. However I have trouble with the EDIT: I logged a separate defect: #7713 |
Thank you for confirming this.
Thank you. It is better to deal with this as a separate issue. |
hello @mkindahl! I confirm no more vacuum license errors in 2.18.2. Thanks! |
What type of bug is this?
Unexpected error
What subsystems and features are affected?
Compression (only with
hypercore
access method)What happened?
Even though my license is correctly set to
timescale
, I get frequent autovacuum errors about an invalid license.variation 1 (while autovacuuming uncompressed chunks)
variation 2 (while autovacuuming compressed chunks)
TimescaleDB version affected
2.18.0, 2.18.1
PostgreSQL version used
16.6
What operating system did you use?
timescaledb-ha:pg16.6-ts2.18.1
What installation method did you use?
Docker
What platform did you run on?
On prem/Self-hosted
How can we reproduce the bug?
Insert 7 million records from the past (February 01-11). Notice the
hypercore
access method in order to use b-tree indexes as described by @mkindahl. If the hypercore am isn't used, there is no autovacuuming bug.This runs for about 30 seconds on my side. I get the following errors in the postgres logs almost immediately after the insert ends.
Afterwards, I can compress the chunks manually. autovacuum keeps failing, but with a slightly different error message:
Compression stats are not working (likely due to no vacuum)
The text was updated successfully, but these errors were encountered: