Thank you for the feed-back. In fact the risk seems neglibible, but it means that at least I'm not misunderstanding what that code does...Tom Lane [EMAIL PROTECTED] ha scritto: paolo romano <[EMAIL PROTECTED]> writes: My doubts now concern MultixactID wrap-around management.
I'm keeping on studying multixact.c and log management, and I hope you can help me, as usual, in clearing my doubts.My doubts now concern MultixactID wrap-around management. Afaics, it is possible to spawn multixactids so quickly to have a wrap-around and to start overwriting the data stored in
ops, i did forget to update the e-mail subject, sorry. I am reposting it with an appropriate one. I'm keeping on studying multixact.c and log management, and I hope you can help me, as usual, in clearing my doubts.My
No, it's not safe to release them until 2nd phase commit.Imagine table foo and table bar. Table bar has a foreign key reference to foo.1. Transaction A inserts a row to bar, referencing row R in foo. This acquires a shared lock on R.2. Transaction A precommits, releasing the lock.3. Transaction B
There is no "regular shared locks" in postgres in that sense. Shared locks are only used for maintaining FK integrity. Or by manually issuing a SELECT FOR SHARE, but that's also for maintaining integrity. MVCC rules take care of the "plain reads". If you're not familiar with MVCC, it's explained
May be this is needed to support savepoints/subtransactions? Or is it something else that i am missing?It's for two-phase commit. A prepared transaction can hold locks that need to be recovered.When a transaction enters (successfully) the prepared state it only retains its exclusive locks and
Tom Lane [EMAIL PROTECTED] ha scritto: paolo romano <[EMAIL PROTECTED]> writes: The point i am missing is the need to be able to completely recover multixacts offsets and members data. These carry information about current transactions holding shared locks on db tuples, which
In PostgreSQL, shared locks are not taken when just reading data. They're used to enforce foreign key constraints. When inserting a row to a table with a foreign key, the row in the parent table is locked to keep another transaction from deleting it. It's not safe to release the lock before end of
<[EMAIL PROTECTED]>Yeah, it's difficult to believe that multixact stuff could form anoticeable fraction of the total WAL load, except perhaps under reallypathological circumstances, because the code just isn't supposed to beexercised often. So I don't think this is worth pursuing. Paolo's freeto
I am working on a possible extension of postgresql mvcc to support very timely failure masking in the context of three-tier applications so i am currently studying Postgresql internals...I am wondering what are the reasons why both the MultiXactIds and the corresponding OFFSETs and MEMBERs are
10 matches
Mail list logo
