13.02.2012 11:51, Nikolay Samofatov wrote:
>
>> Taking into an account that most of users do not need>2Gb of lock
>> table, 64-bit offsets (at least for 2.5) should better remain tunable
>> build parameter, turned off by default.
>
> Great idea, BTW. I haven't thought of a build parameter.
I can a
> -Original Message-
> From: Nikolay Samofatov [mailto:nikolay.samofa...@red-soft.biz]
> Sent: Viernes, 10 de Febrero de 2012 22:00
> Unidentified bug in the wire protocol implementation made one
> of the clients think that cursor
> returned EOF instead of fetch error (causing massi
13.02.2012 9:06, Dmitry Yemanov wrote:
> 13.02.2012 11:51, Nikolay Samofatov wrote:
>>
>>> Taking into an account that most of users do not need>2Gb of lock
>>> table, 64-bit offsets (at least for 2.5) should better remain tunable
>>> build parameter, turned off by default.
>>
>> Great idea, BTW. I
On 02/13/12 11:53, Dmitry Yemanov wrote:
> 13.02.2012 11:39, Alex Peshkoff wrote:
>
>> The simplest part of the task. Just make them offset_t - very logical
>> name for offsets :-)
> It depends on what headers you include. For example, our own offset_t
> defined in File.h is always 64-bit :-)
>
> 11.02.2012 20:03, marius adrian popa wrote:
>
>> I will respond for 2) at first changing the offsets to 64bit doesn't
>> look too hard replace SLONG with SINT64
>> in the lock.cpp functions
>> but i might be wrong so i leave the core dev if is easy
>
> First of all, this must be conditional de
On 02/13/12 13:19, Dimitry Sibiryakov wrote:
> 13.02.2012 9:06, Dmitry Yemanov wrote:
>> 13.02.2012 11:51, Nikolay Samofatov wrote:
Taking into an account that most of users do not need>2Gb of lock
table, 64-bit offsets (at least for 2.5) should better remain tunable
build parameter
13.02.2012 11:37, Alex Peshkoff wrote:
> Later we have plans to have pluggable lock manager, making it possible
> to tune installation.
I don't like the idea to put whole responsibility to DBA because it is hard
to predict
when such tuning may be required.
How about keep 32bits offset, but
13.02.2012 14:13, Vlad Khorsun wrote:
> Imagine x64 CS server and x32 embedded apps at the same time.
> They must share the same lock table...
It was never possible. 64-bit lock table is incompatible with 32-bit one
and it has different version number in the header.
Dmitry
---
13.02.2012 13:45, Alex Peshkoff wrote:
>> I'm not really sure this is strictly required for v2.x. We surely must
>> add an overflow protection, here I agree.
>
> A check in shared memory grow code should do a trick.
Sure.
>> But if it would be possible to
>> have ULONG offsets instead of SLONG,
11.02.2012 20:49, Mark Rotteveel wrote:
> * Is the size being allocated for SQL_TEXT right? It is allocating
> sqllen + 1 and null-terminating it, while looking at the Interbase 6
> ApiGuide they are always allocating sqllen and not null-terminating
You don't have to null-terminate it, sqllen is
On 13-02-2012 13:33, Dmitry Yemanov wrote:
>
>> * For all datatypes other than SQL_VARYING, it is first storing
>> byteArray size and then overwriting that with the byteArray, so actually
>> storing that size first is unnecessary, right?
>
> I'm not sure I understand you here.
>
>> * Is 0x20 (sp
13.02.2012 16:08, Dmitry Yemanov wrote:
> Interesting idea. But how should the conditions like (offset< 0) look
> now? Something like (offset< sizeof(lhb)) doesn't look elegant. Maybe
> explicitly compare with all the magic numbers?
How about (offset < MAX_MAGIC_NUMBER)?
--
SY, SD.
I work with ado.net and when I close the connection, I can still see running
"Netstat -a" that the status of the connection is "ESTABLISHED" though I
closed it.
Can someone refer to that please?
Regards
I. Lesher
--
Tr
On 02/13/12 21:21, Dimitry Sibiryakov wrote:
> 13.02.2012 16:08, Dmitry Yemanov wrote:
>> Interesting idea. But how should the conditions like (offset< 0) look
>> now? Something like (offset< sizeof(lhb)) doesn't look elegant. Maybe
>> explicitly compare with all the magic numbers?
>How abou
14 matches
Mail list logo
