Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane:
>> Go for it. The difficulty I think is testing that the failure path
>> actually does the right thing. Do you have the ability to provoke
>> the failure on demand?
> the easiest way to provoke it is running the following code in a python
> i
Ühel kenal päeval (esmaspäev, 3. jaanuar 2005, 22:29-0500), kirjutas
Bruce Momjian:
> This item still seems open. Is it a TODO?
Probably. It bit me quite badly when it was discovered.
I'm hoping to get something done&tested by tomorrow evenning the latest.
--
Hannu Krosing <[EMAIL PROTECTED]>
Ühel kenal päeval (kolmapäev, 22. detsember 2004, 11:34-0500), kirjutas
Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > It seems that this bug is still lurking in libpq:
> > http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php
>
> > Is anybody working on it, or should I try so
This item still seems open. Is it a TODO?
---
Hannu Krosing wrote:
> It seems that this bug is still lurking in libpq:
>
> http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php
>
> Is anybody working on it, or s
Hannu Krosing <[EMAIL PROTECTED]> writes:
> It seems that this bug is still lurking in libpq:
> http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php
> Is anybody working on it, or should I try something myself, perhaps just
> replacing the lone recv() with pqsecure_read() ?
Go for it.
It seems that this bug is still lurking in libpq:
http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php
Is anybody working on it, or should I try something myself, perhaps just
replacing the lone recv() with pqsecure_read() ?
--
Hannu Krosing <[EMAIL PROTECTED]>
-
