Jim Starkey skriver:
> On 5/13/2014 11:24 AM, Dimitry Sibiryakov wrote:
>> 13.05.2014 17:10, Jim Starkey wrote:
>>> On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote:
> If I'm not mistaken, these repeating index entries works as a
> reference counters and
> allow to stop using stay
Coordinate index numbers between gfix and gstat
---
Key: CORE-4427
URL: http://tracker.firebirdsql.org/browse/CORE-4427
Project: Firebird Core
Issue Type: Improvement
Components: GFIX, GS
Attachments remains in MON$ tables, owners >0 in fb_lock_print result after FB
bugcheck + restart
-
Key: CORE-4426
URL: http://tracker.firebirdsql.org/browse/CORE-4426
13.05.2014 17:43, Jim Starkey wrote:
>For example,
> when cleaning up after a crash, does the code scan all record versions
> to avoiding taking out a single version when the code was expecting a
> double entry?
Nice catch. Yes, if a version don't have all index entries inserting
finished,
On 5/13/2014 11:24 AM, Dimitry Sibiryakov wrote:
> 13.05.2014 17:10, Jim Starkey wrote:
>> On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote:
If I'm not mistaken, these repeating index entries works as a
reference counters and
allow to stop using staying list for indexes even in
13.05.2014 17:10, Jim Starkey wrote:
> On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote:
>> > If I'm not mistaken, these repeating index entries works as a
>> > reference counters and
>> >allow to stop using staying list for indexes even in current code for the
>> >same reason as
>> >for blobs
On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote:
> 10.05.2014 14:03, Vlad Khorsun wrote:
>> As for A-B-A
>> updates i see no problem as there will be 3 separate index entries with own
>> tx numbers. Currently we also have 3 index entires for such scenario, btw.
>> Old IB's optimization to not s
10.05.2014 14:03, Vlad Khorsun wrote:
>As for A-B-A
> updates i see no problem as there will be 3 separate index entries with own
> tx numbers. Currently we also have 3 index entires for such scenario, btw.
> Old IB's optimization to not store existing key second time is not working in
> concur
On 5/13/2014 6:08 AM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> If a record has uncommitted head version created by active transaction
> and some garbage
> in backversions "tail", can anyone (background GC thread, sweep or parallel
> transaction)
> wipe this garbage from the tail while
13.05.2014 14:33, Vlad Khorsun wrote:
> Your code will leave record with broken backversion pointer in case of
> failure while garbage_collect is running. To avoid this, we need to zero
> backpointer before
> garbage_collect. It also have risk to create orphan backversions but it is
> not a big
13.05.2014 14:25, Vlad Khorsun wrote:
>>Actually, it is used in following cases:
>> >
>> >1) Undo with VIO_backout().
>> >2) Undo of update_in_place() in VIO_verb_cleanup().
>> >3) Applying third and following changes of the same record in one
>> >transaction.
> I know. I just a bit lazy
> 12.05.2014 16:30, Vlad Khorsun wrote:
>> Sure. And this is why i wrote recently
>>
>> > currently used way of GC ... not 100% safe in highly concurrent
>> environment.
>
> Can this case be fixed by moving call to delete_record() below
> garbage_collect()?
> Something like this:
>
>
>
> 13.05.2014 13:36, Vlad Khorsun wrote:
>> Yes
>
> How? If I remember your lesson right, garbage in a record is collected only
> if head
> version is marked with transaction number lesser that OAT.
This is a most often case. But, if you look at VIO_chase_record_version,
you'll see
th
13.05.2014 13:36, Vlad Khorsun wrote:
> Yes
How? If I remember your lesson right, garbage in a record is collected only
if head
version is marked with transaction number lesser that OAT.
> list_staying used to undo dead record version. It is not a most often
> operation.
Actual
> If a record has uncommitted head version created by active transaction and
> some garbage
> in backversions "tail", can anyone (background GC thread, sweep or parallel
> transaction)
> wipe this garbage from the tail while the transaction is still active?
Yes
> I can't understand wh
Hello, All.
If a record has uncommitted head version created by active transaction and
some garbage
in backversions "tail", can anyone (background GC thread, sweep or parallel
transaction)
wipe this garbage from the tail while the transaction is still active?
I can't understand why li
16 matches
Mail list logo
