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

From Magnus Hagander
Subject Re: incorrect handling of the timeout in pg_receivexlog
Date
Msg-id CABUevEyjf5q__cAOZhqe_7pwj9U5wmtKiG2Xy9ErQ-S1sXQ3qg@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
Re: incorrect handling of the timeout in pg_receivexlog
List pgsql-hackers
On Thursday, May 10, 2012, Fujii Masao wrote:
On Thu, May 10, 2012 at 11:51 PM, Magnus Hagander <magnus@hagander.net> wrote:
> And taking this a step further - we *already* send these GUCs.
> Previous references to us not doing that were incorrect :-)
>
> So this should be a much easier fix than we thought. And can be done
> entirely in pg_basebackup, meaning we don't need to worry about
> beta...

Sounds good!


Should we go down the easy way and just reject connections when the flag is mismatching between the client and the server (trivial to do - see the attached patch)? Or should we try to implement both floating point and integer in pg_basebackup, and make it work in either case? (We'd still have to reject it if pg_basebackup was compiled without support for int64 at all, of course, but the large majority of cases will have integer timestamps these days, but could be made to support both integer and float for the trivial operations that pg_basebackup actually does).

How common *is* it to have a build that doesn't have integer timestamps these days? Does any of the binary builds do that at all, for example? If it's uncommon enough, I think we should just go with the easy way out...

//Magnus



--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Draft release notes complete
Next
From: "Kevin Grittner"
Date:
Subject: Re: Gsoc2012 idea, tablesample