Thread: CLUSTER, using SHARE UPDATE EXCLUSIVE lock?
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 new table, copying old values to this one, then delete the old one. This would allow Cluster to work with a share update exlusive lock, in order to allow reading the table while cluster is working. How does Cluster actually works? Why making a Cluster command less restrictive isn't even in the TO-list? Best regards, Jonathan Scher
Jonathan Scher <js@oxado.com> 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
Tom Lane a écrit : > Jonathan Scher <js@oxado.com> 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, is it possible to take a share update exclusive lock until the new table is ready, then an access exclusive one only in order to switch tables? I don't think it's already coded like that... Regards Jonathan Scher
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 order to switch > tables? I don't think it's already coded like that... 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. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
> 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 upgrade it to exclusive". Then it would be possible to allow any read-only operation, and to forbid all operation that would need to upgrade. I know that there is a sx_try_upgrade function on freeBSD kernel (man sx), so I guess there is a way to do it, isn't it? Regards, Jonathan Scher