On 19.03.2013 04:42, Peter Eisentraut wrote:
pg_basebackup and pg_receivexlog from 9.3 won't work with earlier
servers anymore. I wonder if this has been fully thought through. We
have put in a lot of effort to make client programs compatible with many
server versions as well as keeping the client/server protocol compatible
across many versions. Both of these assumptions are now being broken,
which will result in all kinds of annoyances.
It seems to me that these tools could probably be enhanced to understand
both old and new formats.
Yes, this was discussed, and the consensus was to break
backwards-compatibility in 9.3, so that we can clean up the protocol to
be architecture-independent. That makes it easier to write portable
clients, from 9.3 onwards. See the thread ending at
http://www.postgresql.org/message-id/4fe2279c.2070...@enterprisedb.com.
Also, using the old tools against new server versions either behaves
funny or silently appears to work, both of which might be a problem.
Hmm, it would be good to fix that. I wonder how, though. The most
straightforward way would be to add an explicit version check in the
clients, in backbranches. That would give a nice error message, but that
would only help with new minor versions.
I think if we are documenting the replication protocol as part of the
frontend/backend protocol and are exposing client tools that use it,
changes need to be done with the same rigor as other protocol changes.
Agreed. The plan is that we're going to be more careful with it from now on.
As far as I can tell, there is no separate version number for the
replication part of the protocol, so either there needs to be one or the
protocol as a whole needs to be updated.
Good point.
I propose that we add a version number, and call the 9.3 version version
2. Let's add a new field to the result set of the IDENTIFY_SYSTEM
command for the replication protocol version number. The version number
should be bumped if the replication protocol is changed in a
non-backwards-compatible way. That includes changes to the messages sent
in the COPY-both mode, after the START_REPLICATION command. If we just
add new commands, there's no need to bump the version; a client can
still check the server version number to determine if a command exists
or not.
We could also try to support old client + new server combination to some
extent by future-proofing the protocol a bit. We could specify that the
client should ignore any message types that it does not understand, and
also add a header length field to the WalData message ('w'), so that we
can add new header fields to it that old clients can just ignore. That
way we can keep the protocol version unchanged if we just add some
optional stuff to it. I'm not sure how useful that is in practice
though; it's not unreasonable that you must upgrade to the latest
client, as long as the new client works with old server versions.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
