This only updates the server packages, hence this can go straight into master

We still have plenty of rebuilds because we haven't split off the postgresql test hook, yet. But certainly the rebuilds are a lot lower than before libpq.

Please note that the client update (#382032) is delayed due to a regression in the release (https://www.postgresql.org/about/news/out-of-cycle-release-scheduled-for-february-20-2025-3016/).

Since the postgresql package exposes psql and libpq as well, I assume that the regression potentially affects this PR as well.

We could probably just try to backport postgres/postgres@a92db3d for a week until the new release is out. We could do the same with libpq, but the usefulness depends a bit on the staging-next cycle.

@vcunat can we get #382032 into the current staging-next cycle? In that case we'd try to backpatch the commit above. If not, then we can also wait for the next release next week (which would probably be too late for staging-next).

Also, what about this PR - master, staging, staging-next? What are our options given https://www.postgresql.org/support/security/CVE-2025-1094/ ?

Added a commit for the postgresqlTestHook issue, then we can try it out right here.

I decided to not fix up the VM tests (they will also build for postgresqlForTests right now) since this will resolve itself when the next staging cycle lands on master.

Added a commit for the postgresqlTestHook issue, then we can try it out right here.

From the libpq commit, I remember there were at least a few cases, where postgresqlTestHook and postgresql were added to the derivation. Those cases would not be caught by this change alone, but let's see how many rebuilds we get with this already :)

Hm, almost no change in rebuilds, yet:

Package: added 1, removed 0, changed 1866, Rebuild: linux 1865, darwin 1684

This push should bring it down a bit.
I left out psycopg2 sicne it seems to pull in postgresql entirely and I'll need to take a closer look. But got some other things to do first.

Almost no change at this stage, yet:

Package: added 1, removed 0, changed 1863, Rebuild: linux 1862, darwin 1682

I looked at the rebuilds a bit:

• ~ 700 are from postgresql + extensions directly. That's the minimum any update to all major versions will always have.
• A lot are python packages, which probably depend on psycopg2. psycopg2 needs to use both libpq and postgresqlForTests. Tested locally, works.
• haskellPackages are not using libpq, yet. This needs a change to cabal2nix, I think.

The changes required for this will need to be made through staging, so I don't think we can bring down the rebuilds in this PR already.

~ 700 are from postgresql + extensions directly. That's the minimum any update to all major versions will always have.

Yeah, right. A little more than I would've guessed :(

I removed the postgresqlForTests patch for now since it doesn't make a real difference.

@vcunat @mweinelt are you OK with staging-next? (~1.8k rebuilds for x86_64-linux - but will be more if we also do libpq here).

Re psql: I guess I'll apply the patch and pull the libpq update here, but this will have to wait until tomorrow.

Yes, send it.

https://www.postgresql.org/message-id/[email protected]

Looks like the security fix introduced a regression.

Looks like the security fix introduced a regression.

Yes, we've been discussing this upthread a little bit and also in #382032.

The idea was to apply the patch to fix the regression, but at this stage we might just as well wait for the new release. While technically the release is made on Thursday, it should be "stamped" (tagged in git) later today already. So by tomorrow morning the latest we should be able to update to 17.4 etc. and be done with it afterwards.

@wolfgangwalther @mweinelt I prepared the relevant changes yesterday (i.e. cherry-picking #382032 and applying the relevant fix), hence I just pushed it.

I'd be fine with both ways, i.e. waiting until the tag is there or going with it now.

Yeah, I guess that was my bad. I understood the time of the "Stamp" commit to be the time of "tag", but that's not true. They "stamped" the release: postgres/postgres@f8554de

But they didn't push the tarballs, yet, and didn't tag this commit, yet. This will happen Thursday.

What's the timeline for current staging-next?

With the stamp done, we could temporarily update to a specific git revision, it would still carry the right version number etc. - I can work on that immediately.

Timeline? I don't think it matters much. All linux binaries are ready now. So even if staging-next got merged to master before this PR, merging to master within days after that would be about the same in terms of rebuilds.

I just pushed updates to the stamped new version by commit rev to this PR (I hope you don't mind pushing to your PR, @Ma27).

We can either go ahead with this now, and then change back to the tag (with the same underlying commit) later this week, or we can wait until the tag appears.

I must admit I still don't understand the whole picture of "why and which rebuilds really matter for a merge to master", and I also don't really know what the implications of both would be in terms of "when will this update hit unstable". So I can't really make the best judgment of the practicality of each approach.

Edit: We should also think about the best course of action for backporting. Can we do this in one go to release-24.11 or do we need to go through staging there as well?

I hope you don't mind pushing to your PR, @Ma27

All good, would've done the same @wolfgangwalther :)

Can we do this in one go to release-24.11 or do we need to go through staging there as well?

staging given the amount of rebuilds.
I'll hopefully get to it this afternoon.

staging given the amount of rebuilds.
I'll hopefully get to it this afternoon.

If we go staging for 24.11, we should certainly wait for the the tags to appear tomorrow, so we don't have to touch it twice. There will certainly not be a difference for how fast this reaches release-24.11.

aarch64-darwin is in trouble:
https://hydra.nixos.org/eval/1812132?filter=postgresql\_&compare=1812115

aarch64-darwin is in trouble: https://hydra.nixos.org/eval/1812132?filter=postgresql_&compare=1812115

Yeah, pretty sure this will be #371242 coming to aarch64-darwin now. We haven't found a solution to this in a while, I doubt I can find one on the spot. But there is #383377, which is at least related - maybe that will help, will look into this today.

It certainly worked fine when I built the PR on the community builder, so the failures are not entirely predictable.

The build passes for me. Maybe it really is flaky.

staging given the amount of rebuilds.
I'll hopefully get to it this afternoon.

If we go staging for 24.11, we should certainly wait for the the tags to appear tomorrow, so we don't have to touch it twice. There will certainly not be a difference for how fast this reaches release-24.11.

I opened #383713 to replace the commits from here with the now pushed tags.

@Ma27 are you going to do the backport?

I'll look into the darwin issue now. Edit: Seems like that was resolved by retriggering the flaky build, at least for now.

The build passes for me. Maybe it really is flaky.

Pretty sure I know why this happens now: #371242 (comment)

If this comes up, the build needs to happen on a different builder, or manual intervention on the builder is required to clean those shared memory segments up - until we can figure out how to prevent that from happening...

@Ma27 are you going to do the backport?

Will do so tomorrow.