On Wed, Jun 6, 2012 at 8:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 5, 2012 at 11:42 PM, Magnus Hagander mag...@hagander.net 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
On Tue, Jun 5, 2012 at 11:42 PM, Magnus Hagander mag...@hagander.net 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
On Fri, May 25, 2012 at 7:56 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, May 24, 2012 at 4:52 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 23, 2012 at 8:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, May 22, 2012 at 11:04 PM, Robert Haas robertmh...@gmail.com
On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander mag...@hagander.net 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
On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander mag...@hagander.net 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,
Magnus Hagander mag...@hagander.net writes:
On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander mag...@hagander.net wrote:
You also removed the safeguard of always sleeping at least 1 second
-
On Tue, Jun 5, 2012 at 4:28 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander mag...@hagander.net
On Thu, May 24, 2012 at 4:52 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 23, 2012 at 8:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, May 22, 2012 at 11:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao masao.fu...@gmail.com
On Tue, May 22, 2012 at 11:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander mag...@hagander.net
wrote:
Should we go down the easy way and just reject connections when the
On Wed, May 23, 2012 at 8:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, May 22, 2012 at 11:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander mag...@hagander.net
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander mag...@hagander.net 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
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander mag...@hagander.net 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
On Thursday, May 10, 2012, Fujii Masao wrote:
On Thu, May 10, 2012 at 11:51 PM, Magnus Hagander
mag...@hagander.netjavascript:;
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
Magnus Hagander mag...@hagander.net 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
On Sat, May 12, 2012 at 12:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
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.fu...@gmail.com wrote:
On Tue, Feb 28, 2012 at 6:08 PM,
On Thu, May 10, 2012 at 3:04 PM, Magnus Hagander mag...@hagander.net 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,
On Thu, May 10, 2012 at 4:43 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, May 10, 2012 at 3:04 PM, Magnus Hagander mag...@hagander.net wrote:
Argh. This thread appears to have been forgotten - sorry about that.
Given that we're taling about a potential protocol change, we really
On Thu, May 10, 2012 at 11:51 PM, Magnus Hagander mag...@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
On Tue, Feb 28, 2012 at 6:08 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 8, 2012 at 1:33 AM, Magnus Hagander mag...@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
On Wed, Feb 8, 2012 at 1:33 AM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Feb 7, 2012 at 17:29, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 07.02.2012 09:03, Fujii Masao wrote:
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masaomasao.fu...@gmail.com 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
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 07.02.2012 09:03, Fujii Masao wrote:
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masaomasao.fu...@gmail.com wrote:
When I compiled HEAD with --disable-integer-datetimes and tested
pg_receivexlog, I
On 07.02.2012 11:35, Magnus Hagander wrote:
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 07.02.2012 11:35, Magnus Hagander wrote:
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So, --statusint needs to be in milliseconds. And while we're at
On Tue, Feb 7, 2012 at 7:06 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 07.02.2012 11:35, Magnus Hagander wrote:
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
On Tue, Feb 7, 2012 at 17:29, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
On Tue, Feb 7, 2012 at 2:58 PM, Fujii Masao masao.fu...@gmail.com 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
32 matches
Mail list logo
