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
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 compatible select().
Nevertheless, currently walreceiver uses t
33 matches
Mail list logo
