On 11-2-2012 17:49, Mark Rotteveel wrote:
On 11-2-2012 16:03, Mark Rotteveel wrote:
And just after I sent my mail I thought of a potential cause which I am
now investigating. It looks like the XSQLVAR sqllen field 4, while the
data array was only 1 entry long. Reducing the sqllen to the actual
The related issue CORE-3701 can be closed (I don't have the rights to do
that).
Mark
--
Mark Rotteveel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud
On 02/11/12 12:18, Claudio Valderrama C. wrote:
-Original Message-
From: Dmitry Yemanov [mailto:firebi...@yandex.ru]
Sent: Sábado, 11 de Febrero de 2012 2:43
11.02.2012 3:19, Adriano dos Santos Fernandes wrote:
Do not think it must be in bid. They must be static in blb IMO.
Dmitry,
On 11.02.2012 20:15, Dmitry Yemanov wrote:
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
Alex,
Taking into an account that most of users do not need2Gb 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.
Nikolay Samofatov
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 :-)
Certainly, a lot of places where lock size is
