11.01.2017 20:59, Alex Peshkoff wrote:
> On 01/11/17 20:36, Vlad Khorsun wrote:
...
>>> I.e. slowdown is obviously present but it's too far from being irresponsive.
>> Thanks. Sad you can't reproduce it.
>
> I remember that long ago linux had some problems with pthread_yield()
> but already do
On 01/11/17 20:36, Vlad Khorsun wrote:
> 11.01.2017 16:01, Alex Peshkoff wrote:
>> On 01/11/17 16:19, Vlad Khorsun wrote:
>>> 11.01.2017 15:09, Alex Peshkoff wrote:
>> Could you try fb2.5 (as i did) ?
> Will do.
>
On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdo
11.01.2017 16:01, Alex Peshkoff wrote:
> On 01/11/17 16:19, Vlad Khorsun wrote:
>> 11.01.2017 15:09, Alex Peshkoff wrote:
>>>
> Could you try fb2.5 (as i did) ?
Will do.
>>> On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown
>>> is present when 'delete from test' i
On 01/11/17 16:19, Vlad Khorsun wrote:
> 11.01.2017 15:09, Alex Peshkoff wrote:
>>
Could you try fb2.5 (as i did) ?
>>> Will do.
>>>
>> On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown
>> is present when 'delete from test' is executed.
> Slowdown of what operation ?
>
sometimes fb_inet_server gets hung for startup
--
Key: CORE-5450
URL: http://tracker.firebirdsql.org/browse/CORE-5450
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.6
Env
On 01/11/17 16:38, Dimitry Sibiryakov wrote:
> 11.01.2017 13:22, Alex Peshkoff wrote:
>> I've used embedded connections.
> That can make a difference as you excluded all operations with security
> database and
> connection handshaking from workflow.
>
>
Be sure - it does not matter here.
--
11.01.2017 13:22, Alex Peshkoff wrote:
> I've used embedded connections.
That can make a difference as you excluded all operations with security
database and
connection handshaking from workflow.
--
WBR, SD.
--
On 01/11/17 16:19, Vlad Khorsun wrote:
> 11.01.2017 15:09, Alex Peshkoff wrote:
>>
Could you try fb2.5 (as i did) ?
>>> Will do.
>>>
>> On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown
>> is present when 'delete from test' is executed.
> Slowdown of what operation ?
11.01.2017 15:09, Alex Peshkoff wrote:
>
>
>>> Could you try fb2.5 (as i did) ?
>> Will do.
>>
>
> On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown
> is present when 'delete from test' is executed.
Slowdown of what operation ?
> Nothing special for GC, but must say that m
>> Could you try fb2.5 (as i did) ?
> Will do.
>
On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown
is present when 'delete from test' is executed.
Nothing special for GC, but must say that master seems to miss even this
slowdown. Rather hard to say for sure cause execution
Support DEFAULT context value in insert, update, merge, etc
---
Key: CORE-5449
URL: http://tracker.firebirdsql.org/browse/CORE-5449
Project: Firebird Core
Issue Type: New Feature
On 01/11/17 15:10, Vlad Khorsun wrote:
> 11.01.2017 13:18, Alex Peshkoff wrote:
>
>> Vlad, I can not reproduce initial issue in master branch on linux.
>> GC does not affect ability to connect to database and execute simple
>> queries.
> Does you tried classic ?
Yes, I've used embedded connect
11.01.2017 13:18, Alex Peshkoff wrote:
> Vlad, I can not reproduce initial issue in master branch on linux.
> GC does not affect ability to connect to database and execute simple
> queries.
Does you tried classic ? Could you try fb2.5 (as i did) ?
Regards,
Vlad
-
FB3 - crash (consistency check) when creating view on table which has column
with character set none, database default charset is utf8, and utf8 default
collation is 'unicode'.
On 01/11/17 14:21, Dimitry Sibiryakov wrote:
> 11.01.2017 12:18, Alex Peshkoff wrote:
>> I can not reproduce initial issue in master branch on linux.
> Can it be issue specific to CentOS?
>
>
That sooner of all can be an issue wih some specific (and not too new)
version of glibc.
But certainl
11.01.2017 12:18, Alex Peshkoff wrote:
> I can not reproduce initial issue in master branch on linux.
Can it be issue specific to CentOS?
--
WBR, SD.
--
Developer Access Program for Intel Xeon Phi Processors
Acce
On 01/11/17 13:16, Vlad Khorsun wrote:
> Hi all,
>
> I tried it on Windows and here is my observations:
> - SuperServer have no problem
>
> - for Classic and SuperClassic problem is confirmed
> of course, operations with another DB's are not affected
>
> - the reason is that attachment doin
Hi all,
I tried it on Windows and here is my observations:
- SuperServer have no problem
- for Classic and SuperClassic problem is confirmed
of course, operations with another DB's are not affected
- the reason is that attachment doing garbage collection doesn't react on AST's:
yes, it
18 matches
Mail list logo
