Re: [PATCHES] Static snapshot data

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Static snapshot data
Date: 2003-05-13 03:55:31
Message-ID: 20030513035531.GF5081@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Mon, May 12, 2003 at 09:40:37AM -0400, Tom Lane wrote:

Moved to -hackers.

> Manfred Koizar <mkoi-pg(at)aon(dot)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!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-05-13 04:51:36 Re: [PATCHES] Static snapshot data
Previous Message Joseph Shraibman 2003-05-13 01:47:00 Re: fomatting an interval (resend)

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-05-13 04:51:36 Re: [PATCHES] Static snapshot data
Previous Message alex avriette 2003-05-12 23:11:34 Re: patch src/bin/psql/help.c