That's lock upgrading, which opens you up to deadlocks. If another
process grabs a lock after your update exclusive, you're not going to
be able to upgrade it.
OK I got the point.
Is it possible to create a new table-level lock mode that says "OK, now
I'm on share level, but soon I will u
On Thu, Mar 01, 2007 at 06:23:37PM +0100, Jonathan Scher wrote:
> >Because when it drops the old copy of the table there had better not be
> >any concurrent readers.
> Then, is it possible to take a share update exclusive lock until the new
> table is ready, then an access exclusive one only in o
Tom Lane a écrit :
Jonathan Scher <[EMAIL PROTECTED]> writes:
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Because when it drops the old copy of the table there had better not be
any concurrent readers.
regards, tom lane
Then
Jonathan Scher <[EMAIL PROTECTED]> writes:
> CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Because when it drops the old copy of the table there had better not be
any concurrent readers.
regards, tom lane
---(end of br
Hello,
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Florian G. Pflug, on a post (
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00081.php )
suggested that there were no way to let the old entry until the command
commit.
I would like Cluster to create a