-
Notifications
You must be signed in to change notification settings - Fork 39
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
Weird UUID behavior after switching to timescaledb-ha #417
Comments
Query plan for both image variants is the same:
|
Your problem is probably caused by a combination of PostgreSQL and TimescaleDB settings for collation and data type casting. When you run a query like |
One important difference between the I suspect that queries which hit the index are the ones which are failing, because the index is corrupted. I would suggest that you rebuild all indexes and try running queries again. |
@JamesGuthrie that makes sense. Tried it and it seems to work fine again. Thanks a lot! |
We have been running a database on the regular timescaledb:latest-pg14 image. We have a table (let's call it entities) where rows are identified by the columns 'TenantId' (uuid) and 'Id' (text).
Now comes the weird part, which we do not understand.
We switched to using timescaledb-ha:pg14-ts2.11 instead, because we want to use postgis. We correctly mounted the old data at /home/postgres... But suddenly, we saw that some queries were not finding entities anymore. When we were listing the entities filtered with
WHERE TenantId = 'some_uuid'
we were seeing the entities, but when we tried querying single ones withWHERE TenantId = 'some_uuid' AND Id = 'some_id'
, we were not matching the entities, even though they clearly existed.Interestingly, when we cast the 'TenantId' colum to 'text' like so
WHERE TenantId::text = 'some_uuid'
it was working again!Now, after switching back to the old timescaledb image, it is working again.The database encoding and collations were exactly the same (utf8 and en_us.utf8)Do you have any idea what is going on here?
UPDATE:
Now seeing this strange behavior in other tables too, even after switching back to the original image.
The text was updated successfully, but these errors were encountered: