Shared PostgreSQL libraries and symbol versioning

From: Pavel Raiskup <praiskup(at)redhat(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Shared PostgreSQL libraries and symbol versioning
Date: 2018-04-05 06:04:34
Message-ID: 5261375.z5KIV9Ssac@nb.usersys.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, for the support of multiple versions of PostgreSQL RPM packages on
one system, we are thinking about having only one libpq.so.5
(libecpg.so.6, libpgtype.so.3 respectively) supported and about building
(linking) all the PostgreSQL package versions against that. The pattern
would mean that we'd have to update the system-wide libraries before
adding support for new PostgreSQL major version and that the older
packages (say version =< 9.6) would be run against libs from newer PG
package (say libpq.so.5 from v10).

Do you think it is a good idea in general? Seems like pg.org [1]
packaging for Debian is doing that already.

As a followup thought; there are probably two major obstacles ATM

- the DSOs' symbols are not yet versioned, and
- the build-system doesn't seem to know how to -lpq link against
external libpq.so

. but technically this this is fixable; so would it be acceptable to
talk about having those two points fixed?

[1] https://www.postgresql.org/download/linux/debian/

Thanks,
Pavel

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-04-05 06:08:26 Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Previous Message Etsuro Fujita 2018-04-05 06:02:08 Re: [HACKERS] Add support for tuple routing to foreign partitions