| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> |
| Cc: | Trond Eivind Glomsrød <teg(at)redhat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, The Hermit Hacker <scrappy(at)hub(dot)org>, Florent Guillaume <efgeor(at)noos(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: Sure enough, the lock file is gone |
| Date: | 2001-01-28 22:53:10 |
| Message-ID: | 5855.980722390@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> I have another question of Peter, Tom, Bruce, or anyone -- is the
> hard-coded socket location in libpq? If so, wouldn't a dynamically
> loaded libpq.so bring this location in for _any_ precompiled, not
> statically-linked, client? Or am I missing something else?
As the 7.1 code presently stands, libpq contains a compiled-in default
socketfile location, which the client code hopefully doesn't know about.
So, yes, if an old client has a dynamically linked libpq.so then
replacing the .so would bring that client into sync with a nonstandard
server. However, the pitfalls should be obvious: independently built
clients, statically linked libraries, differing .so version numbers
to name three risk areas.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-01-28 22:57:54 | Re: Re: Sure enough, the lock file is gone |
| Previous Message | Tom Lane | 2001-01-28 22:47:23 | Re: Re: Sure enough, the lock file is gone |