Maybe surprisingly, when the blob I'm trying to read is all zeros, the
server responds in expected way. Random bytes make it all fall apart.
I have a simple test app, that surfaces it. If some core devs would like
to have a look from the other side.
--
Mgr. Jiří Činčura
Independent IT
On 18-8-2016 00:19, Vlad Khorsun wrote:
>> Considering API calls, network times, etc, I doubt < 1s would be good
>> for anything here.
>
>What about 2500 ms ? :)
>
>I don't insist on milliseconds for statement timeouts. I want to hear more
> opinions. Btw, PG uses milliseconds :)
I'd
On 18-8-2016 17:51, Dimitry Sibiryakov wrote:
>On the other hand it provides DBA a choice, not kill the query
> unconditionally.
>You are not going to make an option "log, but do not kill", are you?..
>
>> PS why do you waste my time speaking about feature you not going to use ?
>
>
Hi *,
if I start firebird using "firebird.exe -a", is there a way to stop it?
In a scripted way.
--
Mgr. Jiří Činčura
Independent IT Specialist
--
Firebird-Devel mailing list, web interface at
On 21-8-2016 09:39, Mark Rotteveel wrote:
> On 18-8-2016 00:19, Vlad Khorsun wrote:
>>> Considering API calls, network times, etc, I doubt < 1s would be good
>>> for anything here.
>>
>>What about 2500 ms ? :)
>>
>>I don't insist on milliseconds for statement timeouts. I want to hear more
Hi *,
when I try to read response to op_get_segment (which works fine without
compression), after flush I only get op_response (9) code and then
nothing is in the stream. The next piece I'm trying to read is 4
bytes/integer for object handle of generic response.
So I clearly get some response