Re: [PATCHES] Static snapshot data
От | Alvaro Herrera |
---|---|
Тема | Re: [PATCHES] Static snapshot data |
Дата | |
Msg-id | 20030513035531.GF5081@dcc.uchile.cl обсуждение исходный текст |
Ответы |
Re: [PATCHES] Static snapshot data
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCHES] Static snapshot data (Manfred Koizar <mkoi-pg@aon.at>) |
Список | pgsql-hackers |
On Mon, May 12, 2003 at 09:40:37AM -0400, Tom Lane wrote: Moved to -hackers. > Manfred Koizar <mkoi-pg@aon.at> writes: > >> And isn't the patch going in quite the wrong > >> direction for nested transactions? > > > Our (Alvaro's and my) current understanding is that snapshots are not > > influenced by nested transactions. > > What was that long article Alvaro posted yesterday, then? He definitely > came to the conclusion that nested transactions need different > QuerySnapshots, and I think it was still open whether they need > different SerializableSnapshots. Well, I'm not sure about this. In fact, if the reasoning below is correct, we can get away with static Serializable- and QuerySnapshots. I don't think it makes sense to change the isolation level for a non-toplevel transaction. That is, if the topmost transaction is ISOLATION LEVEL SERIALIZABLE, all its child transactions will be. And if it's not, then there's no way to make its child transactions be so. Is there an objection to this idea? If there is, all the following is incorrect, I think. With "constant isolation" in mind, it's clear that the SerializableSnapshot is going to be constant for all transactions. We don't need to calculate different SerializableSnapshots for child transactions; thus going with a static variable for SerializableSnapshot isn't wrong. And about QuerySnapshots: given some running transaction with a given QuerySnapshot, a newly created child transaction's first QuerySnapshot can be calculated easily as: - Xmin, Xmax and xip are the same as in the current implementation (i.e. the values from GetSnapshotData) - childxact is my parent's childxact - parentxact is created by adding my parent XID to my parent's parentxact And given some non-topmost ending transaction, its parent transaction next QuerySnapshot can be calculated as: - Xmin, Xmax and xip are the same as in the current implementation - childxact is created by adding the finishing child's XID to its childxact - parentxact is created by removing my own XID from my child's XID. (The border case of a topmost starting transaction's QuerySnapshot is the copy of its SerializableSnapshot, just as it is now). Thus we don't need to keep track of multiple QuerySnapshots either -- the new one can always be calculated from the last one. Please note that yesterday's article contained an error about childxact: we need to know not only what are my own parent's child transactions. We need to know all the XIDs that were completed within the same topmost transaction, because all of them have to be taken into consideration for the visibility rules. IOW, we have to consider all of them like they were only one transaction, discarding the changes made by the ones that were aborted. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Jajaja! Solo hablaba en serio!
В списке pgsql-hackers по дате отправления: