From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres Maillist <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: unix socket location confusion |
Date: | 2015-03-23 05:01:02 |
Message-ID: | 0CA66AE2-6929-41A0-B735-C5B510650486@elevated-dev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Mar 22, 2015, at 10:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> We're entirely at the mercy of the platform's dynamic loader when it comes
> to things like this. I don't think I trust Darwin's loader with relative
> paths; though come to think of it, Linux's loader may be no better. Way
> too many opportunities to screw up there.
It actually does work, I've used it. But I never found any documentation about it, and it was a damned PITA to figure out.
> As for static libraries, there are good reasons why those aren't superior
> solutions. Red Hat for instance has a blanket policy against shipping
> static libraries (with only very narrow exceptions), and I believe the
> same is true of many other vendors.
Yep. Good & bad both ways.
Anyway, I clearly need to not nest specific version builds with the dbs that use that version. I need to build all versions into /usr/local/pgsql-XYZ and then symlink as needed.
--
Scott Ribe
scott_ribe(at)elevated-dev(dot)com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Borodin | 2015-03-23 14:45:12 | Re: [GENERAL] [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary |
Previous Message | Tom Lane | 2015-03-23 04:54:11 | Re: unix socket location confusion |