Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 15

postgresql.org

Post reply on HN
Print view View original

91–100 of 132 posts

Re: PostgreSQL 15

#91

Post by cheald »

Uninen wrote: post #81
jeff-davis wrote: post #67

Earlier quoted context omitted.

The version support is five years: https://www.postgresql.org/support/versioning/ As long as you stay well ahead of that, you are fine. However, I'd strongly recommend testing your applications with new versions as they come out, or in beta (even better). You may learn about new features, find bugs in your application, find bugs in your migration processes, etc. If you bring any problems to the community right away,…

According to https://www.postgresql.org/support/versioning/ the "Final Release" (whatever that means) for v14 is November 2026, and for v15 is November 2024. I wonder if it's a typo or some LTS thing.

Almost certainly a typo. PG releases get 5 years of support.

Re: PostgreSQL 15

#92

Post by thewataccount »

Beltalowda wrote: post #79
samus wrote: post #70

Earlier quoted context omitted.

This will stop working when not enough people adopt .0 versions anymore, because errors from regular usage will not pop up. .0 will become the new beta release that nobody cares about.

I typically update to .0 on my dev machine ASAP, and if there are no problems after a bit I'll update the server to .0 (or usually .1, since that'll usually be out by then). I think that's a nice compromise; although not a "real" test as the load is a lot less. Also things may work in dev but not production, but unless you explicitly use new features that's rare. For larger setups you can us canary servers and whatno…

For context my ideal setup has at least 3 environments - prod, qa/testing before release, and dev. With dev being the most likely to break, and the qa/testing for when we need to be absolutely certain that differences between prod and dev aren't masking any bugs.

I do like the idea of "canary versioning" some stuff. It's a bit of a game theory issue isn't it, since we all need prod to work at all times and can't risk a .0, and a major version difference between dev and prod can mask some nasty issues in my experience.

Re: PostgreSQL 15

#93

Post by systemvoltage »

Just some feedback for releases of any software: I think apt sources and repositories should be ready to go on launch and PR-release so people can immediately use the new version. Looks like that's going to take 2-3 days. Sources are available but that's not something most people want to delve in with make files and dependencies. Something like postgres is huge. Right now, if you go to downloads and expect postgresql-15 available, it is not; lot of people on IRC and elsewhere on Twitter are confused where to download postgresql-15. I know that takes time, so the PR release should just be delayed until apt sources are ready. May be also docker repositories.

Re: PostgreSQL 15

#94

Post by ggregoire »

no_wizard wrote: post #72
hellcow wrote: post #19

> PostgreSQL 15 lets users create views that query data using the permissions of the caller, not the view creator. This option, called security_invoker, adds an additional layer of protection to ensure that view callers have the correct permissions for working with the underlying data. Thank you, kind friends. This is a huge QOL improvement when using row-level security with views and is the top reason I'll be upgrad…

I suspect this will make Supabase very happy! They really believe in row level security as a major line of defense so I imagine this makes it even better

This will be great for PostgREST too.

Re: PostgreSQL 15

#95

Post by tcgv »

thewataccount wrote: post #90
clepto wrote: post #59

Earlier quoted context omitted.

As someone who maintains Postgres 9.2, 9.4, and 9.6 databases. No, they do not. (It is not my will that these databases aren’t on newer versions, I would very much like them to be)

Just curious, is the issue a time thing, or is it on a system that can't easily upgrade it - or is it a breaking changes thing that would require refactors? Basically I'm just curious what broke for you

One main challenge is to upgrade a live large database smoothly, without downtime.

I believe minor version upgrades are easily enough since they maintain disk format compatibility and you can simply spin up a new replica server under the new postgres version and then when it's synched with the main database you can make the switch and kill the old version. I'm not so sure about migrating to a new major version (ex: 9.x to 15.x).

Re: PostgreSQL 15

#96

Post by frant-hartm »

thewataccount wrote: post #89
morley wrote: post #25

I hate to ask a stupid question, but I'm new to administering a Postgres database. Do admins usually upgrade their DBs with each major release? I'm guessing it's highly contextual and depends on how easy it is to do so, but I've heard about places that never upgrade until it's a huge problem for them to do so (in order to avoid an even worse problem.)

I manage two separate projects at my work, I would never upgrade to a .0 update, but we do every update it either when there's features we want, over every ~2~3 years for the general improvements. We use django and some other stuff that has very decent support for postgres, and in my experience postgres updates rarely have breaking changes that require much if any changes for us. This also keeps us from being "trappe…

Note that vendors know this and some release few patch versions quickly with only few patches to make people move to newest version (and get the community test it by using it). No idea if Postgres is one of these.

Re: PostgreSQL 15

#97

Post by jeltz »

anarazel wrote: post #76
jtc331 wrote: post #69

Earlier quoted context omitted.

Isn’t keeping a logical slot alive holding a snapshot?

Not normally, no. A real snapshot is held during the initial creation of the logical slot. After that the slot's "catalog xmin" prevents old catalog (but not user table!) row versions from being removed, but that's somewhat different from a snapshot.

Exactly. We had to disable some cron jobs which abuse temporary tables (and functions!) to avoid catalog bloat but there were no long lived snapshots on the master during the upgrade.

Re: PostgreSQL 15

#98

Post by jeltz »

film42 wrote: post #42
morley wrote: post #25

I hate to ask a stupid question, but I'm new to administering a Postgres database. Do admins usually upgrade their DBs with each major release? I'm guessing it's highly contextual and depends on how easy it is to do so, but I've heard about places that never upgrade until it's a huge problem for them to do so (in order to avoid an even worse problem.)

Corruption of database storage is the biggest fear so most upgrades are done cautiously. Historically postgres versions were released much much slower so the upgrade cadence was slower too. That said, we've been upgrading more frequently, especially since a lot of performance features are being released. So far our upgrades have been executed flawlessly for our cluster of postgres servers (~30 postgres chains each ma…

Jeff is right, PostgreSQL has released a new major yearly the last almost 25 years.

Re: PostgreSQL 15

#99

Post by KajMagnus »

zozbot234 wrote: post #41
andy_ppp wrote: post #12

Earlier quoted context omitted.

Postgres’ history usually suggests they don’t ship broken database features which is why most of us reach for it as a first option when choosing a database. The MSSQL warning sounds bad enough that I’d never use this feature!

Well, the Postgres docs about MERGE include a similar warning: "When MERGE is run concurrently with other commands that modify the target table, the usual transaction isolation rules apply; see [Concurrency control / Transaction isolation] for an explanation on the behavior at each isolation level. You may also wish to consider using INSERT ... ON CONFLICT as an alternative statement which offers the ability to run a…

That's not a warning, instead, it's how it should work, and how one would want it to work, i.e. that the transaction isolation rules apply. Lack of this, would have warranted a warning.

Re: PostgreSQL 15

#100

Post by CoolCold »

samus wrote: post #70
bitwrangler wrote: post #56

Earlier quoted context omitted.

I've heard a saying "just say no to dot oh" -- encouraging one to skip the .0 release and wait until .1 or .2 before doing the upgrade.

This will stop working when not enough people adopt .0 versions anymore, because errors from regular usage will not pop up. .0 will become the new beta release that nobody cares about.

Luckily nowdays we have enough brave persons who just take whatever is postgres:latest image from Docker hub.

Unluckily, chances they will report bugs not that high - at least I don't expect bugs related to any moderate size/loaded databases be found by this way.

Post reply on HN