Hacker News Reader

Comment by manigandham | Hacker News Reader

What is Aiven supposed to do about a bug in Timescale that is still open?

Aiven is great if you don't need the superuser access. They will run some bigger plans on local SSDs and allow you to create replicas and migrate across clouds and regions easily. It's a great way to run multi-cloud without shipping the data yourself. True that they could use more alerting features on resource usage.

GCP managed services of open products are highly unrecommended for this exact reason of being very behind or even obsolete with very limited customization and control. Stick with BigTable, BigQuery, Dataflow and run the rest yourselfs on GCE/GKE.

View on HN

Unfortunately we were not able to offer a concrete workaround in this case, but as mentioned to the author of the post, we were and are in contact with our friends at Timescale to resolve this, and an update with the fix will be available in Aiven shortly.

We are not the upstream for any of the engines running in Aiven, so we work with the upstream developers and communities to resolve any issues found. Often our involvement in fixing the issues is through providing logs, stack traces and other debugging information to the original authors of the code, but in some cases we also fix the issues ourselves and always contribute such fixes back upstream, see e.g. this commit for a PostgreSQL bug that was found by our customers and fixed by us: https://github.com/postgres/postgres/commit/07ef035129586ca2...

> In general, I didn’t understand what added value Aiven.io provides – we weren’t even warned when the database was running out of storage.

We have been considering using Aiven on GCP. Could you comment on the statement above ? cos that's a little worrying.

It's impossible to comment the specific circumstances with the report, but we do generally monitor and warn our users on running low on resources - be it storage, CPU or memory. I admit that the alerting is by no means foolproof; we may miss reaction on rapid or sudden changes in the usage patterns, but the alerting works quite well on more steady and common workloads and usage patterns.

Should the worst case scenario happen and the storage run out, there's always an option to upgrade to the next resource tier size. This will restore the DB state to the latest successfully recorded transaction.

Just FYI - a fix for this bug was merged relatively quickly (within 4 days), and was released just this morning.

https://github.com/timescale/timescaledb/issues/468#issuecom...

Congrats on 1.2, the analytical functions are a good addition.

Thank you :)

Reply on news.ycombinator.com