Re: Strange Behavior with Serializable Transcations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Strange Behavior with Serializable Transcations
Date: 2006-06-30 02:27:02
Message-ID: 19267.1151634422@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris 2006-06-30 02:54:42 Re: psql -h host ...
Previous Message Qingqing Zhou 2006-06-30 02:11:31 Re: Strange Behavior with Serializable Transcations