Re: walreceiver is uninterruptible on win32

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: walreceiver is uninterruptible on win32
Date: 2010-04-17 01:47:00
Message-ID: j2x603c8f071004161847r4c11fb01yfbdcdbe4b45c07f9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 16, 2010 at 3:03 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I have to admit to finding this confusing.  According to the comments:
>>
>> +               /*
>> +                * Don't emulate the PQexec()'s behavior of returning the last
>> +                * result when there are many, since walreceiver never sends a
>> +                * query returning multiple results.
>> +                */
>>
>> ...but it looks like the code actually is implementing some sort of
>> loop-that-returns-the-last result.
>
> Yeah, it's not a very accurate description. And I found another problem:
> libpqrcv_PQexec() ends as soon as an error result arrives even if its
> state has not been PGASYNC_IDLE yet.
>
> So I changed libpqrcv_PQexec() so that it emulates the PQexec()'s behavior
> except the concatenation of error messages. How about the attached patch?

Well, the comment definitely makes more sense in this version. I
can't speak to the behavior.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-04-17 01:47:30 Re: shared_buffers documentation
Previous Message Robert Haas 2010-04-17 00:37:18 Re: shared_buffers documentation