public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jeff Davis <[email protected]>
To: Robert Haas <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: Finnerty, Jim <[email protected]>
Cc: Nasby, Jim <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Collation version tracking for macOS
Date: Tue, 29 Nov 2022 10:46:48 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoYU0SmLYAFQRecgox8Pgn3qRDvrSokEH9jn=+6_jB5Rxg@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKGL36vXMfcaDq+U1ZkoSsdfFnNx7GxhGM7aYzEbKs1W0=Q@mail.gmail.com>
<CA+hUKGKq=iLH3bY+nK7v8b2zBCuKOk-fe0cP0it2RxNaWFVxYA@mail.gmail.com>
<[email protected]>
<CA+hUKG+OSQtrRAk-bHwMJmuvqp-b-LGuxsF2PoDBVyQcT+VEAQ@mail.gmail.com>
<[email protected]>
<CA+hUKGJxg6AbKC9RJ7r1ByVLtvVkThQV+RZO6BKVWYESPCp3Ug@mail.gmail.com>
<CA+TgmoaTGBSLWYHA_TPz9Fc1TOa5aZ=2yXMrGbo9xU225Nv+YA@mail.gmail.com>
<[email protected]>
<CA+TgmoYU0SmLYAFQRecgox8Pgn3qRDvrSokEH9jn=+6_jB5Rxg@mail.gmail.com>
On Tue, 2022-11-29 at 12:32 -0500, Robert Haas wrote:
> You know more about this than I do, for sure, so don't let my vote
> back the project into a bad spot.
I'm going back and forth myself. I haven't found a great answer here
yet.
> But, yeah, the thing you mention
> here is what I'm worried about. Without a way to force a certain
> behavior for a certain particular collation, you don't have an escape
> valve if the global library ordering isn't doing what you want.
One bit of weirdness is that I may have found another ICU problem.
First, install 63.1, and you get (editing for clarity):
$ ls -l /path/to/libicui18n.so.63*
/path/to/libicui18n.so.63 -> libicui18n.so.63.1
/path/to/libicui18n.so.63.1
$ ls -l /path/to/libicuuc.so.63*
/path/to/libicuuc.so.63 -> libicuuc.so.63.1
/path/to/libicuuc.so.63.1
$ ls -l /path/to/libicudata.so.63*
/path/to/libicudata.so.63 -> libicudata.so.63.1
/path/to/lib/libicudata.so.63.1
$ ldd /path/to/libicui18n.so.63.1
libicuuc.so.63 => /path/to/libicuuc.so.63
libicudata.so.63 => /path/to/libicudata.so.63
OK, now install 63.2. Then you get:
$ ls -l /path/to/libicui18n.so.63*
/path/to/libicui18n.so.63 -> libicui18n.so.63.2
/path/to/libicui18n.so.63.1
/path/to/libicui18n.so.63.2
$ ls -l /path/to/libicuuc.so.63*
/path/to/libicuuc.so.63 -> libicuuc.so.63.2
/path/to/libicuuc.so.63.1
/path/to/libicuuc.so.63.2
$ ls -l /path/to/libicudata.so.63*
/path/to/libicudata.so.63 -> libicudata.so.63.2
/path/to/libicudata.so.63.1
/path/to/libicudata.so.63.2
$ ldd /path/to/libicui18n.so.63.2
libicuuc.so.63 => /path/to/libicuuc.so.63
libicudata.so.63 => /path/to/libicudata.so.63
The problem is that the specific minor version 63.1 depends on only the
major version of its ICU link dependencies. When loading
libicui18n.so.63.1, you are actually pulling in libicuuc.so.63.2 and
libicudata.so.63.2.
When I tried this with Thomas's patch, it caused some confusing
problems. I inserted a check that, when you open a library, that the
requested and reported versions match, and the check failed when
multiple minors are installed. In other words, opening
libicui18n.so.63.1 reports a version of 63.2!
(Note: I compiled ICU with --enable-rpath, but I don't think it
matters.)
Summary: even locking down to a minor version does not seem to identify
a specific ICU library, because its shared library dependencies do not
reference a specific minor version.
> It's entirely possible that the scenario I'm worried about is too
> remote in practice to be concerned about. I don't know how this stuff
> works well enough to be certain. It's just that, on the basis of
> previous experience, (1) it's not that uncommon for people to
> actually
> end up in situations that we thought shouldn't ever happen and (2)
> code that deals with collations is more untrustworthy than average.
Yeah...
--
Jeff Davis
PostgreSQL Contributor Team - AWS
view thread (137+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Collation version tracking for macOS
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox