On Fri, Apr 16, 2010 at 09:03, Fujii Masao wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
>> I have to admit to finding this confusing. According to the comments:
>>
>> + /*
>> + * Don't emulate the PQexec()'s behavior of returning the
>> last
>> +
On Fri, Apr 16, 2010 at 4:03 PM, Fujii Masao wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
>> I have to admit to finding this confusing. According to the comments:
>>
>> + /*
>> + * Don't emulate the PQexec()'s behavior of returning the
>> last
>> +
On Fri, Apr 16, 2010 at 3:03 AM, Fujii Masao wrote:
> On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas wrote:
>> I have to admit to finding this confusing. According to the comments:
>>
>> + /*
>> + * Don't emulate the PQexec()'s behavior of returning the
>> last
>> +
On Thu, Apr 15, 2010 at 11:26 PM, Robert Haas 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 n
On Wed, Apr 14, 2010 at 11:13 PM, Fujii Masao wrote:
> On Wed, Apr 14, 2010 at 11:15 PM, Magnus Hagander wrote:
>>> http://archives.postgresql.org/pgsql-hackers/2010-04/msg00077.php
As for the code itself, don't we need a CHECK_FOR_INTERRUPTS in there
for it to be actually useful?
>>>
>
On Thu, Apr 15, 2010 at 5:13 AM, Fujii Masao wrote:
> On Wed, Apr 14, 2010 at 11:15 PM, Magnus Hagander wrote:
The patch also seems confused about whether it's intending to be a
general-purpose solution or not. You can maybe take some shortcuts
if it's only going to be for walrece
On Thu, Apr 15, 2010 at 4:17 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> Looking at the call-sites, there are bugs now - if PQexec() returns
>> NULL, we don't deal with it. It also doesn't always free the result
>> properly. I've added checks for that.
>
> I think you're just adding useless
On Wed, Apr 14, 2010 at 11:15 PM, Magnus Hagander wrote:
>> http://archives.postgresql.org/pgsql-hackers/2010-04/msg00077.php
>>> As for the code itself, don't we need a CHECK_FOR_INTERRUPTS in there
>>> for it to be actually useful?
>>
>> Since the backend version of select() receives any incomin
Magnus Hagander writes:
> Looking at the call-sites, there are bugs now - if PQexec() returns
> NULL, we don't deal with it. It also doesn't always free the result
> properly. I've added checks for that.
I think you're just adding useless complexity there. PQresultStatus
defends itself just fine
On Wed, Apr 14, 2010 at 10:02 AM, Fujii Masao wrote:
> On Tue, Apr 13, 2010 at 9:21 AM, Fujii Masao wrote:
>> On Tue, Apr 13, 2010 at 1:56 AM, Magnus Hagander wrote:
If adding new shared library is too big change at this point, I think
that we should postpone the fix only for dblink to
On Tue, Apr 13, 2010 at 9:21 AM, Fujii Masao wrote:
> On Tue, Apr 13, 2010 at 1:56 AM, Magnus Hagander wrote:
>>> If adding new shared library is too big change at this point, I think
>>> that we should postpone the fix only for dblink to 9.1 or later. Since
>>> no one has complained about this l
On Tue, Apr 13, 2010 at 1:56 AM, Magnus Hagander wrote:
>> If adding new shared library is too big change at this point, I think
>> that we should postpone the fix only for dblink to 9.1 or later. Since
>> no one has complained about this long-term problem of dblink, I'm not
>> sure it really shou
On Mon, Apr 12, 2010 at 13:54, Fujii Masao wrote:
> On Thu, Apr 8, 2010 at 5:01 PM, Fujii Masao wrote:
>>> If it does, there should be
>>> some way to get PGXS to execute that rule as well, I'm sure.
>>
>> If we can copy/link the source file defining "new PQexec" when
>> we compile the dblink, DL
Fujii Masao wrote:
> If adding new shared library is too big change at this point, I think
> that we should postpone the fix only for dblink to 9.1 or later. Since
> no one has complained about this long-term problem of dblink, I'm not
> sure it really should be fixed right now. Thought?
I would a
On Thu, Apr 8, 2010 at 5:01 PM, Fujii Masao wrote:
>> If it does, there should be
>> some way to get PGXS to execute that rule as well, I'm sure.
>
> If we can copy/link the source file defining "new PQexec" when
> we compile the dblink, DLL doesn't seem to be required. So I
> stop creating new DL
On Wed, Apr 7, 2010 at 1:45 AM, Magnus Hagander wrote:
> No, I don't mean that. I mean store it in one place, and copy/link it
> into where it's used. Look at for example how crypt.c and
> getaddrinfo.c are handled in libpq.
Thanks for the advice!
> Not sure how that will play with PGXS, though,
On Tue, Apr 6, 2010 at 2:25 PM, Fujii Masao wrote:
> On Mon, Apr 5, 2010 at 3:18 PM, Fujii Masao wrote:
>> On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander wrote:
>>> More to the point, I'm not sure I like the creation of yet another DLL
>>> to deal with this. The reason this isn't just exported
On Mon, Apr 5, 2010 at 3:18 PM, Fujii Masao wrote:
> On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander wrote:
>> More to the point, I'm not sure I like the creation of yet another DLL
>> to deal with this. The reason this isn't just exported from the main
>> backend is the same reason we created t
On Sat, Apr 3, 2010 at 12:26 AM, Tom Lane wrote:
> I disapprove of the whole approach, actually. The right way to fix this
> is to not touch or replace libpq at all, but to change walreceiver to
> use libpq's async-query facilities directly. Instead of PQexec, use
> PQsendQuery and then a loop i
On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander wrote:
> More to the point, I'm not sure I like the creation of yet another DLL
> to deal with this. The reason this isn't just exported from the main
> backend is the same reason we created the libpqwalreceiver library I'm
> sure - bt that means we
Magnus Hagander writes:
> On Fri, Apr 2, 2010 at 17:26, Tom Lane wrote:
>> I disapprove of the whole approach, actually. The right way to fix this
>> is to not touch or replace libpq at all, but to change walreceiver to
>> use libpq's async-query facilities directly. Instead of PQexec, use
>> P
On Fri, Apr 2, 2010 at 17:26, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Mar 25, 2010 at 15:33, Fujii Masao wrote:
>>> Sorry for the delay. The attached patch replaces PQexec() used by dblink
>>> and libpqwalreceiver with pgwin32_PQexec() which is the win32 version of
>>> PQexec().
>>>
Magnus Hagander writes:
> On Thu, Mar 25, 2010 at 15:33, Fujii Masao wrote:
>> Sorry for the delay. The attached patch replaces PQexec() used by dblink
>> and libpqwalreceiver with pgwin32_PQexec() which is the win32 version of
>> PQexec().
>>
>> pgwin32_PQexec() is provided as the library 'libp
On Thu, Mar 25, 2010 at 15:33, Fujii Masao wrote:
> On Tue, Mar 16, 2010 at 10:35 AM, Fujii Masao wrote:
>>> Just replacing PQexec() with PQsendQuery() is pretty straightforward, we
>>> could put that replacement in a file in port/win32. Replacing
>>> PQconnectdb() is more complicated because you
On Tue, Mar 16, 2010 at 10:35 AM, Fujii Masao wrote:
>> Just replacing PQexec() with PQsendQuery() is pretty straightforward, we
>> could put that replacement in a file in port/win32. Replacing
>> PQconnectdb() is more complicated because you need to handle connection
>> timeout. I suggest that we
On Tue, Mar 16, 2010 at 12:32 AM, Heikki Linnakangas
wrote:
>> Something like libpq_select() which waits for the socket to become
>> ready would be required for walreceiver and dblink. But it's necessary
>> for walreceiver on not only win32 but also the other, ...
>
> Really, why? I thought this i
On 03/15/2010 02:42 AM, Magnus Hagander wrote:
>
> I think we need to look at this as a single problem needing to be
> solved, and then have the same solution applied to dblink and
> walreceiver.
>
+1
Joe
signature.asc
Description: OpenPGP digital signature
Fujii Masao wrote:
> On Mon, Mar 15, 2010 at 6:42 PM, Magnus Hagander wrote:
>> I think we need to look at this as a single problem needing to be
>> solved, and then have the same solution applied to dblink and
>> walreceiver.
Agreed.
> Something like libpq_select() which waits for the socket to
On Mon, Mar 15, 2010 at 6:42 PM, Magnus Hagander wrote:
>>> Perhaps we can factor out most of this
>>> into functions in backend/port/win32 so that we can re-use it fro
>>> there?
>>
>> Sorry. I couldn't get your point. Could you explain it in detail?
>
> What I'm referring to is the part that Hei
On Mon, Mar 15, 2010 at 10:14, Fujii Masao wrote:
> On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander wrote:
>> On Wed, Mar 10, 2010 at 10:09, Fujii Masao wrote:
>>> Hi,
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
>>> On win32, the blocking libpq functions like PQcon
On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander wrote:
> On Wed, Mar 10, 2010 at 10:09, Fujii Masao wrote:
>> Hi,
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
>> On win32, the blocking libpq functions like PQconnectdb() and
>> PQexec() are uninterruptible since they us
On Wed, Mar 10, 2010 at 10:09, Fujii Masao wrote:
> Hi,
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
> On win32, the blocking libpq functions like PQconnectdb() and
> PQexec() are uninterruptible since they use the vanilla select()
> instead of our signal emulation layer c
32 matches
Mail list logo
