--- Tom Lane <[EMAIL PROTECTED]> wrote:
> A simple answer is to have T1 grab an ACCESS
> EXCLUSIVE lock on some
> table to block T2's progress. If that locks out
> third-party
> transactions that you'd rather would go through, you
> can probably use
> a lesser form of lock --- but then both T1 an
Ludwig Lim <[EMAIL PROTECTED]> writes:
> *** For clarification ***
>In the SQL command reference of PostgreSQL:
>in SELECT statement section :
> "The FOR UPDATE clause allows the SELECT
> statement to perform exclusive locking of selected
> rows"
Hmm. That is a misstatement: FOR UPD
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Achilleus Mantzios <[EMAIL PROTECTED]>
> writes:
> >> 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 co
Achilleus Mantzios <[EMAIL PROTECTED]> writes:
>> 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.
ISTM that SERIALIZABLE mode will not s
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
>
On Fri, 18 Oct 2002, Christoph Haller wrote:
> >Suppose I have a transaction (T1) which executes a
> > complicated stored procedure. While T1 is executing,
> > trasaction #2 (T2) begins to execute.
> >
> > T1 take more time to execute that T2 in such a way
> > that T2 finished earlier tha
>Suppose I have a transaction (T1) which executes a
> complicated stored procedure. While T1 is executing,
> trasaction #2 (T2) begins to execute.
>
> T1 take more time to execute that T2 in such a way
> that T2 finished earlier than T1. The result is that
> t2 returns set of data before i
Hi:
Suppose I have a transaction (T1) which executes a
complicated stored procedure. While T1 is executing,
trasaction #2 (T2) begins to execute.
T1 take more time to execute that T2 in such a way
that T2 finished earlier than T1. The result is that
t2 returns set of data before it can
