>> >> So metadata will always works in read-committed mode?
>> >
>> > Yes. This is not good
>>
>> This is "must be" as for me. Any metadata change must be taken in
>> account immediately by every existing connection, except of currently
>> running statements.
>
> If statement runs in RepeatableRead transaction, I'm not sure you are right.
> Why metadata "must be" changed in the middle of such transaction?

Because this transaction is unlucky ;) Well, we may FORCE all transactions
to take new metadata (at least we have such intent ;) so ...

>> > but looks like quite possible compromise for FB3.
>> > Implementing complete RepeatableRead with DDL is much more complicated
>> > task (provided we do not want to have very often conflicts when doing
>> > DDL).
>>
>> I see no value in such mode. Do you offer to long running transaction
>> to work with already dropped table forever ? :)
>
> Yes, certainly. It can read data from the table after DELETE FROM without
> conditions:) Why should DROP behaviour differ? Only because we can't
> implement correct behaviour right now :))

...what the others think ? Is standard contains something in this regards ?

// hvlad: I'm afraid we never be able to implement such "correct behaviour" :)

>> >> 2) Metadata integrity checks (see my reply to Alex) when old versions
>> >> are involved
>> >
>> > OK, I also do not see a good way to solve it without per-process (not
>> > global) RW lock per cache (i.e. per database). Luckily, this lock will be
>> > taken for 'write' only for a very small period of time - when
>> > transaction-level cache is to be merged into global one.
>
> To be precise - when any modification of cache (including load data from
> system tables) is done.
>
>> Currently, when FK constraint is changed, all processes do scan
>> corresponding relation's (load info from database) to pick up this
>> constraint. I see no reason why this will not work in future.
>
> I just wanted to say that to guarantee integrity each data structure,
> accessible from >1 thread, should be protected with a kind of lock. RwLock
> seems to be fine here.

Ah, yes, of course.

Regards,
Vlad