Re: Saif Hakim
> > that is indeed stale, thanks for spotting that. The problem is present
> > in the other distributions as well. I have now manually updated
> > bionic-pgdg, but I will leave the other untouched until I can figure
>
> Thanks!, I've confirmed that my repro no longer works and version 11 is
> installed.
In the meantime I found the issue: to speed up getting the different
PG major versions out for the release, I had told reprepro not to
"export" the Packages files except on the last version processed.
Normally this is fine, since the last run would export all the files
touched, but as the extra components are only touched by a single PG
major version each, the last run had only exported the extra files for
that PG version, leaving the other versions in the old state.
I have now exported all the dists manually again and things will be
back on track in a few minutes with the next mirror run.
> > That said, you shouldn't worry about libpq5 11 - using the 13 version
> > from the "main" repository component is the recommended way.
>
> For my own understanding, what are the ramifications of using the
> non-"main" repository component / what are the differences?
The non-main components contain the lib packages only, so you can't
actually install postgresql-11 from there since that is contained in
"main".
If you want libpq5 only, you can of course go with "11" only (or
"main 11"), but I have yet to hear from a case where libpq5 version 13
isn't just working as well.
> Out of curiosity, if we were running libpq5-11 with Postgres 13, would we
> see any issues or does postgres maintain backwards compatibility with these
> libs as well?
On the client side, you should be able to see much of a difference,
the protocol is the same. Possibly there are some functions in libpq5
that are only available with 13, but dpkg's dependency tracking will
tell you if a newer version is required.
Re: Aaron Pavely
> Actually, I received a few complaints the other day from developers for the
> bionic-pgdg/9.6 component when 9.6.21 was pushed, so Saif's issue was not
> an isolated incident. At the time, I saw that the 'Packages' file was
> similarly last updated in November. Everything looks good now, though.
Nod.
> While I recommend to my teams use the 'main' component for libpq, there
> continues to be fear among many that libpq versions mismatched from the
> parent database cluster version may cause unexpected issues — even after I
> point out that the database cluster itself is using the most recent release
> of libpq from the 'main' component.
Right. (But note that the PG server itself doesn't actually use libpq,
it's only required for things like postgres_fdw and dblink.)
Christoph