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 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 Thursday, October 11, 2012 8:22 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.
Thank you very much.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing
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-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-b
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
.org
> Subject: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w
> breakdown
>
> On Tuesday, October 02, 2012 1:56 PM Heikki Linnakangas wrote:
> On 02.10.2012 10:36, Amit kapila wrote:
> > On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
> >&
On Tuesday, October 02, 2012 1:56 PM Heikki Linnakangas wrote:
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: walsende
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
On Monday, October 01, 2012 8:36 PM Robert Haas wrote:
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 < replica
On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
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
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: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 then KeepAlive
>> message would be s
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 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 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 Wednesday, September 12, 2012 10:15 PM Fujii Masao
>> On Wed, Sep 1
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 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 been logged on the website:
>>>
Bug reference: 7534
>>
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
On Wednesday, September 12, 2012 10:12 PM Magnus Hagander wrote:
On Wed, Sep 12, 2012 at 1: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
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
> Operating system: Suse 10
> Description:
>
> 1. Both master and s
On Wed, Sep 12, 2012 at 1: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
> Operating system: Suse 10
> Description:
>
> 1. Both master and s
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
Operating system: Suse 10
Description:
1. Both master and standby machine are connected normally,
2. then you
39 matches
Mail list logo