Re: Building postgresql with higher major version of separate libpq package

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Patrik Novotny <panovotn(at)redhat(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Building postgresql with higher major version of separate libpq package
Date: 2020-06-23 13:54:48
Message-ID: 2147994.1592920488@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Patrik Novotny <panovotn(at)redhat(dot)com> writes:
> as to my recent findings, I'm not able to build postgresql 10.13
> against libpq 12.1, as in that case, postgresql is missing changes
> implemented in libpq 10.12 (and 12.2) [1].

The commit you cite changed only private, internal details in libpq,
so it's not apparent to me why it would cause FTBFS problems for
clients. Having said that, our build system is in no sense set up
to compile against an external copy of libpq. I suspect that maybe
there's something wrong with the way you've done that. Could you
provide more details about how that's done and what exact problem you
are seeing?

> So to rebase to postgresql
> 10.13 on a system with a separated libpq package shipped at version
> 12.1, I'm required to rebase the libpq package as well (even though
> version 12.1 is technically higher than 10.13, it has been released
> prior to 10.13, and is missing changes included in that version).

On the whole I'm not sure that's a bad thing. Bug fixes made in 10.13
very likely went into the same-vintage 12.x update (ie 12.3) as well;
so if you don't update libpq that may negatively impact stability of
the 10.13 installation.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2020-06-23 13:59:08 Re: Decomposing xml into table
Previous Message Justin Pryzby 2020-06-23 13:53:54 Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)