Thread: clients and libs and versions (oh my)
When version mismatches between the client and server are inevitable, what is less likely to get me into trouble - clients/libs newer than server or server newer than clients/libs? We have dozens of client machines and multiple PG servers in a 24x7x365 operation and I'd like to deploy upgrades in the least risky way possible. Cheers, Steve
Steve Crawford <scrawford@pinpointresearch.com> writes:
> When version mismatches between the client and server are inevitable,
> what is less likely to get me into trouble - clients/libs newer than
> server or server newer than clients/libs?
For the most part I'd update the server first; the exception is that
you'd better be running a pg_dump at least as new as the server.
Also, psql's \d commands are pretty version-specific and frequently fail
if the server is either up-rev or down-rev.
Whichever order you do it in (and most of the time it's probably not
that critical), I'd try to avoid really serious gaps in versions.
7.3 client against 8.1 server, or vice versa, is likely to be a
headache. We do try to maintain cross-version compatibility, but
over more than a couple of releases the gotchas will accumulate.
regards, tom lane
On Tue, Aug 08, 2006 at 02:22:56PM -0700, Steve Crawford wrote: > When version mismatches between the client and server are inevitable, > what is less likely to get me into trouble - clients/libs newer than > server or server newer than clients/libs? Note that you can in theory install multiple versions of the client libraries. People have posted here on the list about setting up aliases to switch between versions. $ pg7.4 $ psql ... runs psql version 7.4 .. $ pg8.1 $ psql ... runs psql version 8.1 ... That way, if version skew is bothering you, you can jump out and use the matching client version for the best results... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.