At 17:52 22.10.00 -0400, you wrote:
[...]
> > First effect I have noticed is that when I write more than a certain
> > amount of data at once using lo_write(), my application hangs
> > indefinitely (10K work perfect, 100K not). Is there a well-known
> > limit? On what does it depend? Or is it an unexpected feature ;-)
>
> > Next off, now that everything runs fine, it does so only when using a
> > local database - when connecting over the network to our test server,
> > i need to put in usleeps of minimum 30ms in between consecutive writes
> > to the same BLOB - else writing fails and i have to close the DB
> > connection to do anything useful with the DB again!
>
>Ugh. FWIW, no one else has reported anything like that, as far as I
>can remember.
Wow - that's interesting. At least the transfersize issue seems unlikely to be
a WIN artefact.
> > I'm afraid i can't give you source code right now, 'cause i'm using
> LabVIEW
> > (a graphical programming language).
>
> > Oh, yes, the local DB is postgreSQL 7.0.2 on cygwin 1.1.4, cygipc 1.0.7.
>
>Maybe it's just my natural dislike for anything Microsoft, but I'm
>suspicious that you are looking at bugs in the Windows TCP/IP stack.
I'd second that - but i can verify that on Linux, given a few moments spare
time.
Perhaps later today.
>Or possibly a cygipc bug. The timing dependency would more or less
>have to be a TCP-level bug, seems like (unless you are trying to use
>the "non blocking output" feature of libpq? That's known not to be
>too reliable, and I don't recommend using it...)
No, i dont use non-blocking mode.
> regards, tom lane
Well, i'll do some tests on Linux then and post the results.
Thanx,
Joerg
