Message-ID: <42930954.2090201@monso.de>
Date: Tue, 24 May 2005 11:00:36 +0000
From: "Jan B." <jan@monso.de>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050514)
MIME-Version: 1.0
To: Rafa Couto <rafacouto@gmail.com>
Cc: Andrew Hammond <ahammond@ca.afilias.info>,
	pgsql-sql@postgresql.org
Subject: Re: Transaction in plpgslq
References: <22df564b05052003479481da1@mail.gmail.com>	
	<428E245B.4050204@ca.afilias.info>
	<22df564b050524034045f8c174@mail.gmail.com>
In-Reply-To: <22df564b050524034045f8c174@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rafa Couto wrote:
> 2005/5/20, Andrew Hammond <ahammond@ca.afilias.info>:
> 
> 
>>The solution to your problem is locking (or concurrency control if you
>>prefer). While we're at it, we might as well optimize your statement a
>>little too using ORDER BY with LIMIT instead of min().
>>
>>SELECT id INTO _contacto_id
>>FROM contactos
>>WHERE contactos.operadora_id IS NULL
>>  AND contactos.actividad_id > = _actividad_id
>>ORDER BY id LIMIT 1
>>FOR UPDATE;
>>
>>Take a look at the "FOR UPDATE" section of the SELECT description for an
>>explanation of how this works.
> 
> 
> 
> I understand "FOR UPDATE" clause is locking while is selecting rows
> only. It does not secure atomic execution from 'SELECT' to 'UPDATE' in
> next statement. Is not it?
> 
> 

After the SELECT FOR UPDATE command locked some rows, other concurrent 
changes to the database could be made, but changes, which require to 
lock that rows will be deferred.

The lock will be hold until the end of the transaction (that means at 
least until the function returns).