Re: Strange Behavior with Serializable Transcations

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote
>> Right, the snapshot does not become set until you do a non-utility
>> command (normally, SELECT/INSERT/UPDATE/DELETE). This is a feature, not
>> a bug, because it lets the transaction take table locks before its
>> snapshot becomes set.

> Hm, mostly I understand it as an optimization. What do you mean by "it lets
> the transaction take table locks before its snapshot becomes set"? If we
> take a snapshot at BEGIN, then the transaction can't take table locks?

It can, but there are cases where you want the lock to be taken before
the snapshot is set. Otherwise, there could be committed changes in the
database that you can't see in your snapshot. I think there are some
examples in the manual, or check the archives.

regards, tom lane