On Thu, Feb 17, 2011 at 4:21 PM, Simon Riggs <simon@2ndquadrant.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@heroku.com> wrote:
>> > On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> >> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina <daniel@heroku.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