Re: Static snapshot data

Alvaro Herrera Munoz <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Fri, May 23, 2003 at 12:17:21PM +0200, Manfred Koizar wrote:
>> If there is not a compelling reason for making things more
>> complicated, I vote for implementing the most simple usable solution,
>> i.e. the whole transaction tree has to run with the same isolation
>> level.

> Ok, I'll do this and if it's needed the other thing can be done later.

I think it would be a real bad idea to proceed on the assumption that
you won't be wanting this ability. There are many things that are
easier to do in SERIALIZABLE mode than otherwise --- especially so if
you can put an error-retry loop around the SERIALIZABLE subtransaction.
To implement such logic entirely in a server-side function, you *must*
be able to do serializable inside read-committed. (I'm assuming here
that when the outer transaction is serializable, every subtransaction
will use the same SerializableSnapshot as the outer transaction. But
then it is impossible to cope with changes committed by concurrent
xacts. You want an outer READ COMMITTED xact so that each successive
retry can start with an up-to-date SerializableSnapshot.)

You may care to read my slides from last year's O'Reilly conference,
if you are not convinced by the above argument.

>> BTW, do we have to invent a new syntax for starting and ending
>> subtransactions? COMMIT/ROLLBACK should be no problem. But does
>> BEGIN [subtransaction] conflict with BEGIN ... END in pl/pgslq?

> I don't think we have to create a new syntax for starting a
> subtransaction in the main parser.

We already have START TRANSACTION and COMMIT. I see no need to invent
any new syntax. We'll just legislate that BEGIN and END continue to
mean what they now do *inside plpgsql*. If you want to manipulate
subtransactions inside plpgsql, then you use the other syntaxes.

regards, tom lane