radimm

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;

Thanks - I will recheck later today.

OP here, damn - that's a very good point. Can't believe I missed it.

This is exactly same struggle for me. Writing technical content about PostgreSQL and balancing my voice without sounding like LLM written is genuinely difficult.

As English is not my first language, I do run into problem where the line between fix my clumsy sentence and rewrite my thought is very thin. Same with writing "boring" technical explanation and more approachable content. I'm getting pushed back for both.

Not OP - but definitely no. In such a case use just physical or - if you have special use case - logical replication that’s built in.

OP here - still have to try (generally operate on VM/bare metal level); but my understanding is that ioctl call would get passed to the underlying volume; i.e. you would have to mount volume

OP here - yes, this is my use case too: integration and regression testing, as well as providing learning environments. It makes working with larger datasets a breeze.

Actually, a "ghost station" shell has existed under Satellite 3 since 1998, though it was never finished or opened to passengers. The tunnel was built that far just to give the trains space to turn around.

Yes, I'm Czech.

I wouldn't usually use the 'non-native speaker argument', but thank you! Just yesterday I was accused of sounding like AI - https://news.ycombinator.com/item?id=46262777 - my default mode is that I oscillate between sounding too boring/technical, or when trying to do my best, sounding like AI

OP here - thank you for mentioning replica, forgot to mention it. Unless it would hit it pretty hard and `hot_standby_feedback` is on

Author here – it’s actually funny, as you pointed out parts that are my own (TM) attempts to make it a bit lighthearted.

LLM is indeed used for correction and improving some sentences, but the rest is my honest attempt at making writing approachable. If you’re willing to invest the time, you can see my fight with technical writing over time if you go through my blog.

(Writing this in the middle of a car wash on my iPhone keyboard ;-)

Author here - thank you for the comments. This article is indeed playing a lot on verge of clickbait and I did asked about that shortly after publishing.

Hey, thank you for follow-up. Really appreciated. This is why I decided to go out and show RegreSQL.

You're absolutely right that in an ideal world, every project would have solid integration tests covering their database access queries. That's the goal everyone should aim for. Unfortunately there again and again cases where developers are afraid of SQL and databases and it's not uncommon to see very simple things sending applications to crawl.

As for the second point, that's a direction I would love to get. Whatever it can be directly, as part of open source or service is something to be decided - but tracking the trend data there would provide a lot of value indeed.

Let me be clear - this is just baseline testing that's only valid for similar data patterns, same cardinality, and so on. Plus it's currently using EXPLAIN, so we're working with estimates, not actual execution data.

But from my experience, this is low-hanging fruit for catching regressions that could break your application without you noticing. The performance work you're describing is the real nitty-gritty database management - the deep optimization work that truly makes or breaks an app.

For that there's no silver bullet.

For now the syntax is not fully compatible - but my goal is to add https://github.com/boringSQL/queries (library behind SQL files parsing) to better align on it. It's definitely on my radar

I'm obviously biased. Adding MySQL support is not that difficult but maintenance is (and ultimately PostgreSQL is better way forward (half joking :))

With current feature set it's something I have already considered but still undecided.

OP here - I'm going to follow up with the separate article on pgTap. But the goals of both tools is slightly different in my mind.

For now only fixtures support transaction as cleanup options, but that's a good point that tested queries might also modify the queries.

I will definitely reach out, just give me bit of time to mentally recover from the exposure and got some meet ups where I promised to deliver some presentations and they will consume a lot of my spare free time.

It's not unreasonable view - noted, will add to my list. Thank you!

At this point it supports initialization through the fixtures systems (like inline SQL or SQL files). At the moment they have fixed order, which might lead to some limitations, but I'm already thinking about some pre/post test setup hooks and full schema handling as well (for full schema reloads).

Plus I have whole set of other requirements where RegreSQL suddenly seems to be a good solution.

And without sounding cliche - Thank you for the comment! This is exactly why I forced myself to go public and get this level of feedback.

The primary direction is to make RegreSQL part of CI/CD pipelines. In theory in can be run against production DB, but I believe it needs much more work to provide real value there. Thank you for the comment!

OP here - I do agree some of the problems that come with SQL/ORM queries are pretty horrendous and that's exactly where I would like RegreSQL going. For now I can't promise the particular direction, but comments like this are the reason why I pushed myself to release it and keep it beyond my own playground. Thank you!