Re: Replication server timeout patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication server timeout patch
Date: 2011-02-17 21:42:32
Message-ID: AANLkTikpK_wencrj_me_x=cUgQA+Ejr1C22da9sN0mgZ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 17, 2011 at 4:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Wed, 2011-02-16 at 11:34 +0900, Fujii Masao wrote:
>> On Tue, Feb 15, 2011 at 7:13 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
>> > On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> >> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
>> >>> Context diff equivalent attached.
>> >>
>> >> Thanks for the patch!
>> >>
>> >> As I said before, the timeout which this patch provides doesn't work well
>> >> when the walsender gets blocked in sending WAL. At first, we would
>> >> need to implement a non-blocking write function as an infrastructure
>> >> of the replication timeout, I think.
>> >> http://archives.postgresql.org/message-id/AANLkTi%3DPu2ne%3DVO-%2BCLMXLQh9y85qumLCbBP15CjnyUS%40mail.gmail.com
>> >
>> > Interesting point...if that's accepted as required-for-commit, what
>> > are the perceptions of the odds that, presuming I can write the code
>> > quickly enough, that there's enough infrastructure/ports already in
>> > postgres to allow for a non-blocking write on all our supported
>> > platforms?
>>
>> I'm not sure if there's already enough infrastructure for a non-blocking
>> write. But the patch which I submitted before might help to implement that.
>> http://archives.postgresql.org/message-id/AANLkTinSvcdAYryNfZqd0wepyh1Pf7YX6Q0KxhZjas6a%40mail.gmail.com
>
> So, in summary, the position is that we have a timeout, but that timeout
> doesn't work in all cases. But it does work in some, so that seems
> enough for me to say "let's commit". Not committing gives us nothing at
> all, which is as much use as a chocolate teapot.
>
> I will be looking to commit this tomorrow morning, unless I hear some
> clear No comments, with reasons.

I guess the question is whether it works in 10% of cases or 95% of
cases. In the first case there's probably no point in pretending we
have a feature if it doesn't really work. In the second case, it
might make sense. But I don't have a good feeling for which it is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-17 21:43:12 Re: btree_gist (was: CommitFest progress - or lack thereof)
Previous Message Jesper Krogh 2011-02-17 21:24:52 Estimates not taking null_frac element into account with @@ operator? (8.4 .. git-head)