From: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 23:00:35 |
Message-ID: | 3A74A493.6FCC9AC3@wgcr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
Of course, with the server and client on the same machine, the server
and the client dynamic libs are very likely to follow the same
'non-standard' as the libpq.so is likely to be from the same build or
package as the server is.
> However, the pitfalls should be obvious: independently built
> clients, statically linked libraries, differing .so version numbers
> to name three risk areas.
These are real risks, of course. I have personal experience with the
statically linked client and differing so version number cases.
And, yes, to echo your previous sentiment, if it breaks, the
distributor/packager is not the one that gets the compliants -- the
PostgreSQL community does.
So, for future discussion, a compromise will have to be arranged -- but
this really isn't a 7.1 issue, as this isn't a 'bugfix' per se -- you
have fixed the immediate problem. But this is something to consider for
7.2 or later, as priorities are shuffled.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From | Date | Subject | |
---|---|---|---|
Next Message | Franck Martin | 2001-01-28 23:05:40 | Development of ISO19100 support in PG |
Previous Message | Tom Lane | 2001-01-28 22:59:42 | Re: Re: Sure enough, the lock file is gone |