Fix assertion failures introduced by psycopg 3.2.4

[cosgroveb]

These failures were previously addressed by @AndrewJackson2020
in #1249 by pinning psycopg to 3.2.3. I became aware of this because I
just re-enabled the python test suite in Debian1 2.

This is a good change in psycopg3. Let's update the assertions and bump
the version.

Open question around whether or not we should pin here? It would be good if
we can sort these issues out before they block the upload of new
pgbouncer packages to downstream distros (although most folks probably
care more about pgdg?) No worries either way.

[AndrewJackson2020]

Thank you for doing this.

I am on team pin. Further I think we should pin every version of every package in the requirements.txt file as long as it passes CI. I think that in an ideal world 2 runs of CI should produce the exact same results every single time, and pinning gets us closer to that.

[df7cb]

Fwiw, pinning won't help with Debian, we will be using the package that is present in the release targeted, ignoring any pins.

[cosgroveb]

@df7cb

Fwiw, pinning won't help with Debian, we will be using the package that is present in the release targeted, ignoring any pins.

Yeah, that's a more explicit way of stating what I was trying to say here:

Open question around whether or not we should pin here? It would be good if
we can sort these issues out before they block the upload of new
pgbouncer packages to downstream distros (although most folks probably
care more about pgdg?) No worries either way.

[cosgroveb]

I am on team pin. Further I think we should pin every version of every package in the requirements.txt file as long as it passes CI.

This approach works well for internal platform teams that have mirrors and aren't disrupted e.g. when a package is pulled but IMHO it's less realistic for an OSS project being distributed across several OSes and packaging systems. I agree at least that there's a time and place for it.

[df7cb]

Afaict requirements.txt is just ignored by most parts of the Debian toolchain. If you insist on pinning to a version that behaves differently, we will poke you with a stick until the regression tests are working again for Debian and apt.postgresql.org. 😁

[df7cb]

That said, https://jengus.postgresql.org/job/pgbouncer-binaries/102/architecture=amd64,distribution=sid/console is unhappy and we'd appreciate a new release with this PR merged. 😸

[AndrewJackson2020]

Is the idea with removing pins that any upstream packager will always pull the most recent versions of any python packages so the pgbouncer requirements.txt should always pull the most recent version even if that means a successful build yesterday could mean a failed build today?

[cosgroveb]

Yes. We should aim for our test suite to be compatible with all of the versions of our dependencies that downstream packagers will use and a build failure tomorrow is precisely how that is accomplished.

We definitely want our tests passing in Debian. To get the signal that we need we must not pin.

[JelteF]

Is the idea with removing pins that any upstream packager will always pull the most recent versions of any python packages so the pgbouncer requirements.txt should always pull the most recent version even if that means a successful build yesterday could mean a failed build today?

Yeah, I think that's a fair assesment. And I think that's a reasonable tradeoff. Packaging is definitely a case where we cannot force a specific python dependency version on people, so we should just make sure that we work with all. And then we'll just have to live with the fact that we need to fix our build sometimes (for which a temporary workaround can be to pin the version).