Argh. This thread appears to have been forgotten - sorry about that.
Given that we're taling about a potential protocol change, we really
should resolve this before we wrap beta, no?
On Thu, Mar 29, 2012 at 6:43 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Feb 28, 2012 at 6:08 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Feb 8, 2012 at 1:33 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> Will it break using pg_basebackup 9.2 on a 9.1 server, though? that
>>> would also be very useful in the scenario of the central server...
>>
>> No unless I'm missing something. Because pg_basebackup doesn't use
>> any message which is defined in walprotocol.h if "-x stream" option is
>> not specified.
>
> No, this is not right at all :( Changing TimestampTz fields in 9.2 would break
> that use case.
>
> If we support that use case, pg_basebackup 9.2 must know which an integer
> or a double is used for TimestampTz in 9.1 server. Otherwise pg_basebackup
> cannot process a WAL data message proporly. But unfortunately there is no
> way for pg_basebackup 9.2 to know that... 9.1 has no API to report the actual
> datatype of its TimestampTz field.
>
> One idea to support that use case is to add new command-line option into
> pg_basebackup, which specifies the datatype of TimestampTz field. You can
> use one pg_basebackup 9.2 executable on 9.1 server whether
> --disable-integer-datetimes is specified or not. But I'm not really sure if it's
> worth doing this, because ISTM that it's rare to build a server and a
> client with
> the different choice about TimestampTz datatype.
I think that's survivable - but what will things look like if they do
mismatch? Can we detect "abnormal values" somewhere and at least abort
in a controlled fashion saying "sorry, wrong build flags"?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/