Tomas Vondra wrote > Also, the current phrasing "If the NOWAIT option is specified then the > command will fail if it is unable to acquire all of the locks required > immediately." seems a bit ambiguous to me. Maybe it's just me, but I > wasn't sure if that means "locks for all objects immediately, before > actually starting moving them to the new tablespace", and I had to check > to code that I understand it correctly. But maybe that's just me and > it's unambiguous to everyone else. Well, it would be really strange if > it behaved differently ...
If you weren't sure that it meant "locks for all objects [first]..." what did you think it could have meant instead? NOWAIT semantics seem fairly straight-forward in that at no point do I want to wait to get a lock so unless I can get all my locks right now give up and let me try again when I am ready. Once you have all the locks feel free to do your thing cause the locks you hold will prevent you from having to wait for someone else during your processing (aside from resource contention anyways). Note from the ALTER TABLE documentation section: "All tables in the current database in a tablespace can be moved by using the ALL IN TABLESPACE form, which will lock all tables to be moved first and then move each one." This immediately precedes the comment about NOWAIT so there is not need to reason things out... Is there inconsistency between the different objects types with regard to the wording in the documentation? I may nitpick the wording itself but at least for TABLE there is no ambiguity that I can see. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/SET-TABLESPACE-NOWAIT-tp5825098p5825107.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers