Re: Locking that will delayed a SELECT

From: Achilleus Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
To: Christoph Haller <ch(at)rodos(dot)fzk(dot)de>
Cc: lud_nowhere_man(at)yahoo(dot)com, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Locking that will delayed a SELECT
Date: 2002-10-18 08:32:51
Message-ID: Pine.LNX.4.44.0210181128130.14163-100000@matrix.gatewaynet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Fri, 18 Oct 2002, Achilleus Mantzios wrote:

> Second small xaction T2's select statemenst will use values commited
> before these select statements started. That is, these queries
> will NOT see values updated by T1.
>
> The problem is solved
>
> a) Using SERIALIZABLE XACTION ISOLATION LEVEL
> b) in T2 using "select for update" instead of select. That way T2's
> queries will wait untill T1's statements commit or rollback.
>
> The SERIALIZABLE XACTION ISOLATION LEVEL scheme is heavier
> and thus maybe less efficient.

Also the serialization must be secured from the application side.
In your case the program invoking T2 must be prepared to retry
the transaction if T1 commits in the meantime.

With SERIALIZABLE XACTION ISOLATION LEVEL T2's select statements
will use values commited before T2 began (and not before
these select statements began as in the READ COMMITED
(default) XACTION ISOLATION LEVEL case)

==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill(at)matrix(dot)gatewaynet(dot)com
mantzios(at)softlab(dot)ece(dot)ntua(dot)gr

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message wishy wishy 2002-10-18 10:24:50 Re: date
Previous Message Achilleus Mantzios 2002-10-18 08:19:14 Re: Locking that will delayed a SELECT