On 30.10.2014 23:19, David G Johnston wrote: > 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...
EINSUFFICIENTCAFFEINE I guess ... I was already in slighly confused mode because of something else, and apparently I skipped the sentence about locking all the tables first. So nevermind, let's forget this ever happened, OK? Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers