Note about upcoming instability in FE/BE protocol
I am about to start committing changes to CVS tip to implement the
planned FE/BE protocol changes. My plan is to do this a bit at a time,
since I don't want to get far out of sync with CVS. This means that the
actual protocol supported by CVS tip is going to change little by
little. Yesterday's libpq may or may not talk to today's server.
To try to keep people from wasting time chasing version-skew problems
while this goes on, I have devised the following plan. The server and
libpq will claim to speak protocol numbers 3.100, 3.101, 3.102, etc,
changing each time a visible change is committed. There is also a
temporary hack in postmaster.c that will reject connections from clients
claiming to speak 3.anything-other-than-postmaster's-version. If you
have an out-of-sync libpq, you will get something like
FATAL: unsupported frontend protocol 3.110: server supports 1.0 to 3.109
or
FATAL: Your development libpq is out of sync with the server
After the dust settles, I'll reset the protocol version number to 3.0
for release.
Note that this should only affect libpq. Other clients may continue to
speak protocol 2.0 while this is going on, and that should not change.
In emergency you should be able to use a 7.3 copy of libpq.so to talk to
the CVS-tip server.
regards, tom lane
On Thu, 2003-04-17 at 23:23, Tom Lane wrote:
After the dust settles, I'll reset the protocol version number to 3.0
for release.
And you will need to increment the shared library's major version
number, won't you? That will be libpq.so.4, so perhaps the final
protocol version should be 4 too.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"For by grace are ye saved through faith; and that not
of yourselves; it is the gift of God, not of works,
lest any man should boast." Ephesians 2:8,9
Oliver Elphick <olly@lfix.co.uk> writes:
And you will need to increment the shared library's major version
number, won't you?
Not unless I break application binary compatibility ...
regards, tom lane
Did you ever get my post about making the BE protocol implemented as a
shared library?
Tom Lane wrote:
Show quoted text
I am about to start committing changes to CVS tip to implement the
planned FE/BE protocol changes. My plan is to do this a bit at a time,
since I don't want to get far out of sync with CVS. This means that the
actual protocol supported by CVS tip is going to change little by
little. Yesterday's libpq may or may not talk to today's server.To try to keep people from wasting time chasing version-skew problems
while this goes on, I have devised the following plan. The server and
libpq will claim to speak protocol numbers 3.100, 3.101, 3.102, etc,
changing each time a visible change is committed. There is also a
temporary hack in postmaster.c that will reject connections from clients
claiming to speak 3.anything-other-than-postmaster's-version. If you
have an out-of-sync libpq, you will get something like
FATAL: unsupported frontend protocol 3.110: server supports 1.0 to 3.109
or
FATAL: Your development libpq is out of sync with the serverAfter the dust settles, I'll reset the protocol version number to 3.0
for release.Note that this should only affect libpq. Other clients may continue to
speak protocol 2.0 while this is going on, and that should not change.
In emergency you should be able to use a 7.3 copy of libpq.so to talk to
the CVS-tip server.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
mlw <pgsql@mohawksoft.com> writes:
Did you ever get my post about making the BE protocol implemented as a
shared library?
Yeah. I'm not planning to think about it in this development cycle,
though. There's enough on my plate already, and no compelling reason
why such a change would need to be done now rather than later.
regards, tom lane