From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-19 14:11:29 |
Message-ID: | t2l9837222c1004190711n7d3e3c7cy4601c646f367de9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 16, 2010 at 09:03, 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?
Applied with only minor stylistic changes. Thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-04-19 14:21:17 | Re: shared_buffers documentation |
Previous Message | Tom Lane | 2010-04-19 13:48:01 | Re: CTAS not honoring NOT NULL, DEFAULT modifiers |