On Sat, Nov 15, 2025 at 02:10:49PM -0800, Adrian Klaver wrote: ! On 11/15/25 12:25, Peter 'PMc' Much wrote:
! > required. So it's a balance. And in recent years, the modernizations ! > often happened to curtate in delightfulness (with PostgreSQL sadly ! > not being an exception). ! ! Where is delightfulness short changed in?: ! ! https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-HIGHLIGHTS Oh yes, these are fine things, and I know people will be delighted. But, honestly, none of them would make me upgrade, as I do not currently have a specific usecase. Recap: The last time I was really overjoyed, that was when Erwin Brandstetter showed me about window functions and with- clauses, and what they can do: https://stackoverflow.com/a/36659866/6201427 I didn't understand that immediately (because when you do everything, and try to do it in-depth, you cannot do it quickly also, you have to choose two of these three). But it was that feeling, wow, there are things to learn, and it will get better and better. Now for the downside, there are these usual sources of frustration that just do happen. For instance, whenever I get into the mood of doing a bit of lengthy SQL coding, I end up at the point where some erratic fluctuations of execution times appear, like 50 vs. 2000 ms for the same query with roughly the same amount of rows, just some different timestamps in the payload. But these things do happen, the web has a lot of articles on switching off nestloop, and you can't store statistics for a CTE before invoking the query. The greater trouble comes from things being "improved" to cater for stupidity. In most cases that doesn't make things better. And the postgtreSQL example for this would be the backup scheme - that is a funny little story about how to overwrite your production database (well, if you consider that funny): With Rel.13 came a new fashion of backup, and I was against it. I think I mentioned it here, and that was not well received - it's necessary for safety, was the bottomline. So I sat down and wrote the new backup routine, all precisely according to the book - since my backup tool didn't have anything suitable to offer, at that time. Then finally, last year or so, they (Bareos) came along with a proper backup routine, and I wanted to switch. But before retiring my own script, I wanted to see if the restore would actually work as smooth as I had imagined. (I do not normally do restore tests, I think the logical proof that the correct data is saved to the correct place, should suffice.) So I created some filespaces and did the test restore. All went fine, so far. I carefully read the manual (section 26.3.4. in the Rel.15 manual) and noticed item 4: If you are using tablespaces, you should verify that the symbolic links in pg_tblspc/ were correctly restored. Oh yes, I thought, a good point! They were obviousely NOT correct for a test restore: they pointed into the production tablespace. I fixed them appropriately, and assumed that should do the trick. Then I started the rollforward show. Some one or two hours into the flight, I was wondering why my test partitions had no disk traffic. Then I noticed that my production tablespaces had a lot of disk traffic. And then I figured the rest: the new backup scheme requires that a file "tablespace_map" gets included in the backup. And then obviousely also in the restore. The server had found that file, had happily deleted my carefully crafted symlinks and replaced them with some new ones created from that file - which now again pointed into the *production* filespace. And that was it with the production database. Crap, I thought - I told them not to do it. They did it nevertheless, "for safety", as they said. And now we see what that "safety" can do. Corrollary: Its the same as with the public transport here. I tell them, that doesn't work, they say "don't worry and shut up", and in the end I have to pay the price. (Specifically, they wanted to switch from paper tickets to chipcard. I said, as a passenger I cannot ensure that such a chipcard would work correctly, because I didn't build it and not even have means check if it is working. Doesn't matter, they said, for the customer nothing does change. It took about two years for that cheapest-vendor-chip to go dead, and then they charged me penalty. See our terms of service, they said: when the chip doesn't work, then you have failed to present a valid ticket and therefore are a fare dodger and get punished.) Well, over all, nothing really bad had happened. I did another, real restore, and found that there hadn't been any transactions in the critical timeframe - because the timeline didn't switch. (That's another little gotcha: if we do point-in-time restore, and give a point-in-time that is *after* the last recorded transaction, then the rollforward does not fully complete, and the timeline does not switch. But the stuff works nevertheless.) cheers, PMc
