Re: incorrect handling of the timeout in pg_receivexlog - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: incorrect handling of the timeout in pg_receivexlog
Date
Msg-id CAHGQGwFToYdUP1RP9PpKW7W=y=VhffMWawpMMTX4=aPTJ9NZMg@mail.gmail.com
Whole thread Raw
In response to Re: incorrect handling of the timeout in pg_receivexlog  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: incorrect handling of the timeout in pg_receivexlog  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: patch for parallel pg_dump
Next
From: Hitoshi Harada
Date:
Subject: Re: Finer Extension dependencies