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
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 |