On Tue, Nov 13, 2012 at 1:06 PM, Amit kapila wrote:
> On Monday, November 12, 2012 8:23 PM Fujii Masao wrote:
> On Fri, Nov 9, 2012 at 3:03 PM, Amit Kapila wrote:
>> On Thursday, November 08, 2012 10:42 PM Fujii Masao wrote:
>>> On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila
>>> wrote:
>>> > On Thu
On Fri, Nov 9, 2012 at 3:03 PM, Amit Kapila wrote:
> On Thursday, November 08, 2012 10:42 PM Fujii Masao wrote:
>> On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila
>> wrote:
>> > On Thursday, November 08, 2012 2:04 PM Heikki Linnakangas wrote:
>> >> On 19.10.2012 14:42, Amit kapila wrote:
>> >> > On T
On Thursday, November 08, 2012 10:42 PM Fujii Masao wrote:
> On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila
> wrote:
> > On Thursday, November 08, 2012 2:04 PM Heikki Linnakangas wrote:
> >> On 19.10.2012 14:42, Amit kapila wrote:
> >> > On Thursday, October 18, 2012 8:49 PM Fujii Masao wrote:
> >> >
On Thu, Nov 8, 2012 at 5:53 PM, Amit Kapila wrote:
> On Thursday, November 08, 2012 2:04 PM Heikki Linnakangas wrote:
>> On 19.10.2012 14:42, Amit kapila wrote:
>> > On Thursday, October 18, 2012 8:49 PM Fujii Masao wrote:
>> >> Before implementing the timeout parameter, I think that it's better
>
On Fri, Nov 9, 2012 at 1:40 AM, Fujii Masao wrote:
> On Thu, Nov 8, 2012 at 2:22 AM, Heikki Linnakangas
> wrote:
>> On 16.10.2012 15:31, Heikki Linnakangas wrote:
>>>
>>> On 15.10.2012 19:31, Fujii Masao wrote:
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
>
On Thu, Nov 8, 2012 at 2:22 AM, Heikki Linnakangas
wrote:
> On 16.10.2012 15:31, Heikki Linnakangas wrote:
>>
>> On 15.10.2012 19:31, Fujii Masao wrote:
>>>
>>> On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
>>> wrote:
On 15.10.2012 13:13, Heikki Linnakangas wrote:
>
>
>>>
On Thursday, November 08, 2012 2:04 PM Heikki Linnakangas wrote:
> On 19.10.2012 14:42, Amit kapila wrote:
> > On Thursday, October 18, 2012 8:49 PM Fujii Masao wrote:
> >> Before implementing the timeout parameter, I think that it's better
> to change
> >> both pg_basebackup background process and
On 19.10.2012 14:42, Amit kapila wrote:
On Thursday, October 18, 2012 8:49 PM Fujii Masao wrote:
Before implementing the timeout parameter, I think that it's better to change
both pg_basebackup background process and pg_receivexlog so that they
send back the reply message immediately when they r
On 16.10.2012 15:31, Heikki Linnakangas wrote:
On 15.10.2012 19:31, Fujii Masao wrote:
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
On 15.10.2012 13:13, Heikki Linnakangas wrote:
Oh, I didn't remember that we've documented the specific structs
that we
pass around. It's quite b
On Tue, Oct 16, 2012 at 9:31 PM, Heikki Linnakangas
wrote:
> On 15.10.2012 19:31, Fujii Masao wrote:
>>
>> On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 15.10.2012 13:13, Heikki Linnakangas wrote:
Oh, I didn't remember that we've documented the specific
On Wed, Oct 17, 2012 at 8:46 PM, Amit Kapila wrote:
>> On Monday, October 15, 2012 3:43 PM Heikki Linnakangas wrote:
>> On 13.10.2012 19:35, Fujii Masao wrote:
>> > On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
>> > wrote:
>> >> Ok, thanks. Committed.
>> >
>> > I found one typo. The attac
On Wednesday, October 17, 2012 5:16 PM Amit Kapila wrote:
> > On Monday, October 15, 2012 3:43 PM Heikki Linnakangas wrote:
> > On 13.10.2012 19:35, Fujii Masao wrote:
> > > On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
> > > wrote:
> > >> Ok, thanks. Committed.
> > >
> > > I found one typ
> On Monday, October 15, 2012 3:43 PM Heikki Linnakangas wrote:
> On 13.10.2012 19:35, Fujii Masao wrote:
> > On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
> > wrote:
> >> Ok, thanks. Committed.
> >
> > I found one typo. The attached patch fixes that typo.
>
> Thanks, fixed.
>
> > ISTM y
On 15.10.2012 19:31, Fujii Masao wrote:
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
On 15.10.2012 13:13, Heikki Linnakangas wrote:
Oh, I didn't remember that we've documented the specific structs that we
pass around. It's quite bogus anyway to explain the messages the way we
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
> On 15.10.2012 13:13, Heikki Linnakangas wrote:
>>
>> On 13.10.2012 19:35, Fujii Masao wrote:
>>>
>>> ISTM you need to update the protocol.sgml because you added
>>> the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage.
>
On 15.10.2012 13:13, Heikki Linnakangas wrote:
On 13.10.2012 19:35, Fujii Masao wrote:
ISTM you need to update the protocol.sgml because you added
the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage.
Oh, I didn't remember that we've documented the specific structs that we
pass
On 13.10.2012 19:35, Fujii Masao wrote:
On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
wrote:
Ok, thanks. Committed.
I found one typo. The attached patch fixes that typo.
Thanks, fixed.
ISTM you need to update the protocol.sgml because you added
the field 'replyRequested' to WalSnd
On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
wrote:
> On 11.10.2012 13:17, Amit Kapila wrote:
>>>
>>> How does this look now?
>>
>>
>> The Patch is fine and test results are also fine.
>
>
> Ok, thanks. Committed.
I found one typo. The attached patch fixes that typo.
ISTM you need to upd
On 11.10.2012 13:17, Amit Kapila wrote:
How does this look now?
The Patch is fine and test results are also fine.
Ok, thanks. Committed.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Wednesday, October 10, 2012 9:15 PM Heikki Linnakangas wrote:
> On 04.10.2012 13:12, Amit kapila wrote:
> > Following changes are done to support replication timeout in sender as
> well as receiver:
> >
> > 1. One new configuration parameter wal_receiver_timeout is added to
> detect timeout at
On 04.10.2012 13:12, Amit kapila wrote:
Following changes are done to support replication timeout in sender as well as
receiver:
1. One new configuration parameter wal_receiver_timeout is added to detect
timeout at receiver task.
2. Existing parameter replication_timeout is renamed to wal_send
On Tuesday, October 09, 2012 6:00 PM Robert Haas wrote:
> On Mon, Oct 8, 2012 at 10:42 AM, Amit Kapila
> wrote:
> > How about following:
> > 1. replication_client_timeout -- shouldn't it be client as new
> configuration
> > is for wal receiver
> > 2. replication_standby_timeout
>
> ISTM that the
On Mon, Oct 8, 2012 at 10:42 AM, Amit Kapila wrote:
> How about following:
> 1. replication_client_timeout -- shouldn't it be client as new configuration
> is for wal receiver
> 2. replication_standby_timeout
ISTM that the client and the standby are the same thing.
> If we introduce a new parame
> On Monday, October 08, 2012 7:38 PM Robert Haas wrote:
> On Thu, Oct 4, 2012 at 6:12 AM, Amit kapila
> wrote:
> > 1. One new configuration parameter wal_receiver_timeout is added to
> detect timeout at receiver task.
> > 2. Existing parameter replication_timeout is renamed to
> wal_sender_timeou
On Thu, Oct 4, 2012 at 6:12 AM, Amit kapila wrote:
> 1. One new configuration parameter wal_receiver_timeout is added to detect
> timeout at receiver task.
> 2. Existing parameter replication_timeout is renamed to wal_sender_timeout.
-1 from me on a backward compatibility break here. I don't kn
> -Original Message-
> From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-
> ow...@postgresql.org] On Behalf Of Amit kapila
> Sent: Thursday, October 04, 2012 3:43 PM
> To: Heikki Linnakangas
> Cc: Fujii Masao; pgsql-b...@postgresql.org; pgsql-hackers@postgresql.org
> Subject: Re: [
On 02.10.2012 10:36, Amit kapila wrote:
On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
So let's think how this should ideally work from a user's point of view.
I think there should be just two settings: walsender_timeout and
walreceiver_timeout. walsender_timeout specifies how lon
Excerpts from Robert Haas's message of lun oct 01 21:02:54 -0300 2012:
> On Mon, Oct 1, 2012 at 12:57 PM, Fujii Masao wrote:
> > I believe many users are basically familiar with TCP keepalives and how to
> > specify it. So I think that this approach would be intuitive to users.
>
> My experience
On Mon, Oct 1, 2012 at 12:57 PM, Fujii Masao wrote:
> I believe many users are basically familiar with TCP keepalives and how to
> specify it. So I think that this approach would be intuitive to users.
My experience is that many users are unfamiliar with TCP keepalives
and that when given the opt
On Mon, Oct 1, 2012 at 7:38 PM, Heikki Linnakangas
wrote:
> Hmm, I think we need to step back a bit. I've never liked the way
> replication_timeout works, where it's the user's responsibility to set
> wal_receiver_status_interval < replication_timeout. It's not very
> user-friendly. I'd rather not
On Mon, Oct 1, 2012 at 6:38 AM, Heikki Linnakangas
wrote:
> Hmm, I think we need to step back a bit. I've never liked the way
> replication_timeout works, where it's the user's responsibility to set
> wal_receiver_status_interval < replication_timeout. It's not very
> user-friendly. I'd rather not
On 21.09.2012 14:18, Amit kapila wrote:
On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
Approach-2 :
Provide a variable wal_send_status_interval, such that if this is 0, then
the current behavior would prevail and if its non-zero th
On Tuesday, September 18, 2012 6:03 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
>> To define the behavior correctly, according to me there are 2 options
now:
>
>> Approach-1 :
>> Document that both(sender and receiver) the timeout parameters should be
>> greater than
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
> To define the behavior correctly, according to me there are 2 options now:
>
> Approach-1 :
> Document that both(sender and receiver) the timeout parameters should be
> greater than wal_receiver_status_interval.
> If both are greater, then I th
On Sunday, September 16, 2012 12:14 AM Fujii Masao wrote:
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila
wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fujii Masao
>> On Thu,
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fujii Masao
>> On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
>>> On Wednes
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>
> On Thursday, September 13, 2012 10:57 PM Fujii Masao
> On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
>> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
>> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
> The following bug has bee
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 7534
>>> Logged by: Amit Kapila
>>> Email address:
On Wednesday, September 12, 2012 10:15 PM Fujii Masao
On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7534
>> Logged by: Amit Kapila
>> Email address: amit.kap...@huawei.com
>> PostgreSQL version: 9.2.0
>> Operat
39 matches
Mail list logo
