Dmitry Yemanov wrote:

>A read-only transaction can modify a generator value which requires an
>immediate page write. If generator page writes are made defered, then they
>should have precedence over all data/index pages.
>

I'm talking about a transaction that didn't do writes, not a transaction
declared read-only; in specific, transactions that don't have the
TRA_write flag set. An update reference to a generator sets this bit.

However, a change to a generator is performed with a simple mark (no
force-write). This is safe because the generator page will always be
flushed before a transaction is committed.

In any case, a generator is only guaranteed unique if the transaction
commits. The only circumstances in which it isn't is when the system
crashes or is stopped before the generator page is written.

>
>
>
>>The obvious solution to group commits is a commit thread that
>>periodically wakes up, checks for transactions pending completion,
>>updates the header page if dirty, flushes dirty pages belonging to
>>transactions pending commit, then updates the tip. All pending
>>transactions are then committed. A plausible commit cycle would be four
>>or five times a second, but would, of course, be settable by
>>configuration file. Lets call it five times a second for discussion.
>>
>>
>
>It means a defered cache page flushing, correct? I.e.
>isc_commit_transaction() returns immediately although the data was not
>actually written yet? I.e. it introduces the same level of reliability (or
>lack of it) as the asynchronous writes, but preserves the careful write
>order and require less page writes? I mean a time interval for the data of
>the committed transactions to be lost in the case of failure.
>
>
>

The transaction would not be reported committed until after the
transaction has been committed.


[Non-text portions of this message have been removed]