Re: walreceiver is uninterruptible on win32

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/

In response to

Browse pgsql-hackers by date

  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