Re: backward incompatible pg_basebackup and pg_receivexlog - Mailing list pgsql-hackers

On Tue, Mar 19, 2013 at 11:39 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> 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.2070506@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.

Still better to do it in a backbranch, than not at all. At least we
are then nicer to the ones that do keep up with upgrades, which we
recommend they do...


>> 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.

+1.

> 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.

Sounds good.


> 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.

I think that's quite reasonable, as long as we detect it, and can give
a nice error message telling the user how to deal with it.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/