radimm

OP, here thank you for comments and while I might not like it to be called LLM - I give up.

well, let's say it depends what audince. This particular topic came as part of talks I deliver on Postgres internals and my webinars. Same story. Again and again.

But I do get the point. Here the goal was - there's no perfect solution. Just characteristics to be aware of.

Given the anti-LLM sentiment here I need to get offline and not get affected by it.

OP here, thanks for the feedback. Just curious - anything specific? I spent long time getting to some sort of framework for my writing and being called LLM is my constant struggle.

PS: I do use LLM for polish, etc.

I had to make a cut - and that's also a reason why etcd got mentioned - focused on what most people today know.

OP here, I acctually had Firebird listed in some version of my draft, but had to make a natural cut somewhere.

OP here - thanks for feedback. They weren't in prompt because there wasn't any (for polish yeah, not hiding it).

OP here - correct, I guess I should clarify soon.

Thank you! And you are right. Many people forgot about idle-in-transaction backends.

Full comparison https://docs.hetzner.com/general/infrastructure-and-availabi...

For example CPX 42 went from € 0.0408/h (25.49 per month) to € 0.1114/h (69.49 per month).

Was expecting price hike but not this level.

Markus never fails to deliver. I actually haven’t realised how SQL standard handles ORDER BY on non-selected columns by just rewriting the SELECT clause behind your back.

Separation of concerns ruthlessly broken ;-)))

Somehow it feel HOT updates are very confusing. You can also try to play with interactive visualizer to understand it better https://boringsql.com/visualizers/hot-updates/

This is the message the author posted on LinkedIn:

After a lot of thought, I have decided to stop working on pgBackRest. I did not come to this decision lightly. pgBackRest has been my passion project for the last thirteen years, and I was fortunate to have corporate sponsorship for much of this time, but there were also many late nights and weekends as I worked to make pgBackRest the project it is today, aided by numerous contributors. Every open-source developer knows exactly what I mean and how much of your life gets devoted to a special project.

Since Crunchy Data was sold, I have been maintaining pgBackRest and looking for a position that would allow me to continue the work, but so far I have not been successful. Likewise, my efforts to secure sponsorship have also fallen far short of what I need to make the project viable.

Like everyone else, I need to make a living, and the range of pgBackRest-related roles is very limited. I can now consider a wider variety of opportunities, but those will not leave me time to work on pgBackRest, which requires a fair amount of time for maintenance, bug fixes, PR reviews, answering issues, etc. That does not even include time to write new features, which is what I really love to do. Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop.

I will post a notice of obsolescence and archive the repository. I imagine at some point pgBackRest will be forked, but that will be a new project with new maintainers, and they will need to build trust the same way we did.

Again, many thanks to all the pgBackRest contributors over the years. It was a pleasure working with you!

One of the benefit is that instead of LLM blindly advising you to do

> ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

it can advise you to

-- Step 1: backfill NULLs UPDATE customers SET email = 'unknown-' || id || '@example.com' WHERE email IS NULL;

-- Step 2: add constraint without full table scan ALTER TABLE customers ADD CONSTRAINT customers_email_not_null CHECK (email IS NOT NULL) NOT VALID;

-- Step 3: validate in the background with a weaker lock ALTER TABLE customers VALIDATE CONSTRAINT customers_email_not_null;