On Wed, Jun 6, 2012 at 8:10 PM, Fujii Masao wrote:
> On Tue, Jun 5, 2012 at 11:42 PM, Magnus Hagander wrote:
>> Works for me. We still need a (reworked) patch, though, right? We just
>> move where the move between seconds and milliseconds happens?
>
> Attached is the updated version of the patch.
On Tue, Jun 5, 2012 at 11:42 PM, Magnus Hagander wrote:
> Works for me. We still need a (reworked) patch, though, right? We just
> move where the move between seconds and milliseconds happens?
Attached is the updated version of the patch.
> I definitely don't think we need subsecond granularity
On Tue, Jun 5, 2012 at 4:28 PM, Fujii Masao wrote:
> On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander wrote:
>> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
>>> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
You also removed the "safeguard" of always sleeping at least 1 secon
On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander wrote:
> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
>> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
>>> You also removed the "safeguard" of always sleeping at least 1 second
>>> - should we keep some level of safeguard there, eve
Magnus Hagander writes:
> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
>> We discussed this before and reached consensus not to use %m :)
>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01674.php
> :-) there goes my memory.
> That said, we're using %m in a fairly large number o
On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
>> It contains a number of unrelated changes of %m -> %s - what's the
>> motivation for those?
>
> %m in fprintf() is glibc extension according to man page, so it's not portable
> and shoul
On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
> It contains a number of unrelated changes of %m -> %s - what's the
> motivation for those?
%m in fprintf() is glibc extension according to man page, so it's not portable
and should not be used, I think.
We discussed this before and reached
On Fri, May 25, 2012 at 7:56 PM, Fujii Masao wrote:
> On Thu, May 24, 2012 at 4:52 AM, Magnus Hagander wrote:
>> On Wed, May 23, 2012 at 8:11 PM, Fujii Masao wrote:
>>> On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
> On Fri, M
On Thu, May 24, 2012 at 4:52 AM, Magnus Hagander wrote:
> On Wed, May 23, 2012 at 8:11 PM, Fujii Masao wrote:
>> On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
>>> On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander
wrote:
On Wed, May 23, 2012 at 8:11 PM, Fujii Masao wrote:
> On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
>> On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
>>> On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander
>>> wrote:
Should we go down the easy way and just reject connections whe
On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
> On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
>> On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander
>> wrote:
>>> Should we go down the easy way and just reject connections when the flag is
>>> mismatching between the client and the se
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
> On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander wrote:
>> 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)?
>
> + c
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander wrote:
> 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)?
+ char *tmpparam;
You forgot to add "const" before "char"
On Sat, May 12, 2012 at 12:44 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> 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
Magnus Hagander writes:
> 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...
+1 for just rejecting a mismatch.
On Thursday, May 10, 2012, Fujii Masao wrote:
> On Thu, May 10, 2012 at 11:51 PM, Magnus Hagander
> >
> 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 tho
On Thu, May 10, 2012 at 11:51 PM, Magnus Hagander 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 d
On Thu, May 10, 2012 at 4:43 PM, Magnus Hagander wrote:
> On Thu, May 10, 2012 at 3:04 PM, Magnus Hagander wrote:
>> 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 wra
On Thu, May 10, 2012 at 3:04 PM, Magnus Hagander wrote:
> 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?
Had a chat with Heikki about this, and we came to
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 wrote:
> On Tue, Feb 28, 2012 at 6:08 PM, Fujii Masao wrote:
>> On
On Tue, Feb 28, 2012 at 6:08 PM, Fujii Masao wrote:
> On Wed, Feb 8, 2012 at 1:33 AM, Magnus Hagander 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
On Wed, Feb 8, 2012 at 1:33 AM, Magnus Hagander wrote:
> On Tue, Feb 7, 2012 at 17:29, Heikki Linnakangas
> wrote:
>> On 07.02.2012 16:55, Tom Lane wrote:
>>>
>>> (The integer vs float TimestampTz issue is a kind of portability
>>> problem, but we've already bought into the assumption that sender
On Tue, Feb 7, 2012 at 17:29, Heikki Linnakangas
wrote:
> On 07.02.2012 16:55, Tom Lane wrote:
>>
>> (The integer vs float TimestampTz issue is a kind of portability
>> problem, but we've already bought into the assumption that sender and
>> receiver must be built with the same choice, no?)
>
>
>
On 07.02.2012 16:55, Tom Lane wrote:
(The integer vs float TimestampTz issue is a kind of portability
problem, but we've already bought into the assumption that sender and
receiver must be built with the same choice, no?)
Hmm, true. In hindsight, I think that was a bad choice, but it's a bit
l
Heikki Linnakangas writes:
> On 07.02.2012 09:03, Fujii Masao wrote:
>> What about changing receivelog.c so that it uses time_t instead of
>> TimestampTz? Which would make the code simpler, I think.
> Hmm, that would reduce granularity to seconds.
It also creates portability issues that I'd just
On Tue, Feb 7, 2012 at 7:06 PM, Magnus Hagander wrote:
> On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
> wrote:
>> On 07.02.2012 11:35, Magnus Hagander wrote:
>>>
>>> On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
>>> wrote:
So, --statusint needs to be in milliseconds. And while
On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
wrote:
> On 07.02.2012 11:35, Magnus Hagander wrote:
>>
>> On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
>> wrote:
>>>
>>> So, --statusint needs to be in milliseconds. And while we're at it, how
>>>
>>> difficult would be to ask the server for
On 07.02.2012 11:35, Magnus Hagander wrote:
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
wrote:
So, --statusint needs to be in milliseconds. And while we're at it, how
difficult would be to ask the server for the current value of
replication_timeout, and set --statusint automatically based
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
wrote:
> On 07.02.2012 09:03, Fujii Masao wrote:
>>
>> On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao wrote:
>>>
>>> When I compiled HEAD with --disable-integer-datetimes and tested
>>>
>>> pg_receivexlog, I encountered unexpected replication timeout.
On 07.02.2012 09:03, Fujii Masao wrote:
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao wrote:
When I compiled HEAD with --disable-integer-datetimes and tested
pg_receivexlog, I encountered unexpected replication timeout. As
far as I read the pg_receivexlog code, the cause of this problem is
that p
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao wrote:
> Hi,
>
> When I compiled HEAD with --disable-integer-datetimes and tested
> pg_receivexlog, I encountered unexpected replication timeout. As
> far as I read the pg_receivexlog code, the cause of this problem is
> that pg_receivexlog handles the s
Hi,
When I compiled HEAD with --disable-integer-datetimes and tested
pg_receivexlog, I encountered unexpected replication timeout. As
far as I read the pg_receivexlog code, the cause of this problem is
that pg_receivexlog handles the standby message timeout incorrectly
in --disable-integer-datetim
32 matches
Mail list logo
