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.