Обсуждение: SET TABLESPACE ... NOWAIT

Hi,

while preparing an overview of features new in 9.4, I noticed that while
we provide NOWAIT for the "ALTER ... ALL IN TABLESPACE" commands, we
don't support that for the 'single object' case. Is that on purpose? I
assume it makes, as with a single object you can't get stuck half-way
through, but I don't see it mentioned in any of the discussions (both
for the original patch in January and the summer reworks).

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 ...

Tomas

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.

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