On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:
> ... and I know Jeff read that quite closely because he raised a
> question off-list about an error he found in it which managed to
> survive the many editing and review passes that paper went through.
> :-)
Well, I need to keep up with the discussion on the interaction of
temporal and SSI :-)
> I think the behavior is correct because a function's control flow
> might be directed by what it reads in a subtransaction, even if it
> rolls back -- and the transaction as a whole might leave the
> database in a different state based on that than if it had read
> different data (from a later snapshot). For example, if a plpgsql
> function has a BEGIN/EXCEPTION/END block, it might read something
> from the database and use what it reads to attempt some write. If
> that write fails and the EXCEPTION code writes something, then the
> database could be put into a state which is dependent on the data
> read in the subtransaction, even though that subtransaction is
> rolled back without the client ever directly seeing what was read.
On reflection, I agree with that. Trying to puzzle through your
transactions (and application logic) to see if you are depending on any
information read in an aborted subtransaction is exactly the kind of
thing SSI was meant to avoid.
> This strikes me as significantly different from returning some rows
> to a client application and then throwing an error for the
> transaction as a whole, because the client will certainly have an
> opportunity to see the failure (or at worst, see a broken connection
> before being notified of a successful commit).
Oh, I see the distinction you're making: in PL/pgSQL, the exception
mechanism involves *implicit* subtransaction rollbacks. That's more of a
language issue, but a valid point.
I'm still not sure I see a theoretical difference, but it does seem wise
to keep predicate locks for aborted subtransactions.
> > If so, I think we need a documentation update. The serializable
> > isolation level docs don't quite make it clear that
> > serializability only applies to transactions that commit. It might
> > not be obvious to a user that there's a difference between commit
> > and abort for a RO transaction. I think that, in S2PL,
> > serializability applies even to aborted transactions (though I
> > haven't spent much time thinking about it), so users accustomed to
> > other truly-serializable implementations might be surprised.
>
> That's a fair point. Do you have any suggested wording...
I'll write something up. Can I document that you may depend on the
results read in aborted subtransactions, or should I leave that
undefined for now?
Regards,Jeff Davis
