> Changing gbak so it backs up user enhancements to the system tables is just
> programming, and restoring them after the base table are created isn't hard,
> but both go against the V3 goal of shutting users out of system space.
It depends on your view/definition of "system space" or "system ob
On Thu, Apr 3, 2014 at 2:06 PM, Claudio Valderrama C. wrote:
>
>
>
> AFAIK, you can put triggers on sys tables and they last until the last
> attachment finished. When the db is loaded again, those triggers do not
> load. I don't know if that changed recently, but was this way since I
> remember.
Hi Sean,
you misunderstud my context. I do not talk about result of cloning but about
implementation of clone process by FB developers. When i talk about copying
data i talk about transaction data like flags, tip ... not database data like
records...
Regards,
Karol Bieniaszewski
- Reply m
Problems when a table grows beyond 65535 pointer pages
--
Key: CORE-4384
URL: http://tracker.firebirdsql.org/browse/CORE-4384
Project: Firebird Core
Issue Type: Bug
Components: En
Yes, I mean ZFS. Brain fade.
Thanks for catching that.
On 4/4/2014 12:17 AM, marius adrian popa wrote:
> sun xfs is zfs right ?
>
> I will check how the GLP/apache and mpl2 linking works but i know why
> they are using in libreoffice (practical reasons)
> https://wiki.documentfoundation.org/Deve
On 4/4/2014 9:53 AM, Leyne, Sean wrote:
> Adriano,
>
>> Instead of get from info and pass "everything" (possible MBs?) in the TPB,
>> isn't possible to pass only the "base transaction number" of cloned
>> transaction, and them the engine instances dumps necessary information,
>> like with monitorin
On 4/4/2014 9:43 AM, Dimitry Sibiryakov wrote:
> 04.04.2014 15:37, Alex Peshkoff wrote:
>> On 04/04/14 17:01, James Starkey wrote:
>>> An alternate solution that is close is thread specific sub-pools, which is
>>> nice because a thread specific sub-pool doesn't even need interlocked
>>> instruction
Karol,
> Take into account that user can rollback or commit oryginal transaction
> before we copy all data to clone. Is this a problem or is simple to clone
> transaction in atomic way?
Given that the clone would have the details of an **active** transaction, it
would be isolated from any other
On 04/04/14 17:43, Dimitry Sibiryakov wrote:
> 04.04.2014 15:37, Alex Peshkoff wrote:
>> On 04/04/14 17:01, James Starkey wrote:
>>> An alternate solution that is close is thread specific sub-pools, which is
>>> nice because a thread specific sub-pool doesn't even need interlocked
>>> instructions.
Adriano,
> Instead of get from info and pass "everything" (possible MBs?) in the TPB,
> isn't possible to pass only the "base transaction number" of cloned
> transaction, and them the engine instances dumps necessary information,
> like with monitoring, so the new transaction could reconstruct the
04.04.2014 15:37, Alex Peshkoff wrote:
> On 04/04/14 17:01, James Starkey wrote:
>> An alternate solution that is close is thread specific sub-pools, which is
>> nice because a thread specific sub-pool doesn't even need interlocked
>> instructions. It does require a fetch of thread specific data o
On 04/04/14 17:01, James Starkey wrote:
> I know of many very smart people who have tried to lick this problem
> without success. Iy feels like there should be a solution, but avoiding an
> ABA problem on release seems insurmountable.
From what I've read the only good solution for ABA problem is
Index and BLOBs garbage collection doesn't work for update_in_place()
-
Key: CORE-4383
URL: http://tracker.firebirdsql.org/browse/CORE-4383
Project: Firebird Core
Issue Type
I know of many very smart people who have tried to lick this problem
without success. Iy feels like there should be a solution, but avoiding an
ABA problem on release seems insurmountable.
An alternate solution that is close is thread specific sub-pools, which is
nice because a thread specific su
Savepoints are not released on commit
-
Key: CORE-4382
URL: http://tracker.firebirdsql.org/browse/CORE-4382
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 3.0 Alp
04.04.2014 10:46, Alex Peshkoff wrote:
> update_in_place() is also used often enough
> updating same record in one transaction more than once is not something
> outstanding
IMHO, couple of memory allocation can't spoil it if you take into account,
for example,
usage of list_staying() with co
On 04/04/14 12:16, Dimitry Sibiryakov wrote:
> 04.04.2014 9:00, Alex Peshkoff wrote:
>> In yvalve you were saying absolutely contrary things - to save 2 atomic
>> ops you were going to delay deallocation of objects in providers and
>> providers themself.
> Yes, and I was told (by you) that savi
04.04.2014 9:00, Alex Peshkoff wrote:
> In yvalve you were saying absolutely contrary things - to save 2 atomic
> ops you were going to delay deallocation of objects in providers and
> providers themself.
Yes, and I was told (by you) that saving CPU clocks is pointless but RAM is
precious
and
On 04/03/14 21:25, Dimitry Sibiryakov wrote:
> 03.04.2014 18:52, Dmitry Yemanov wrote:
> > You destroy those buffer via AutoPtr when they get out of scope.
> > Instead, you could release those buffers for reuse at the end of the
> > same scope.
>
>I.e. duplicate code from memory pool in jrd_tr
19 matches
Mail list logo
