The short answer is "don't CLUSTER while the table is in live use" ...
This is kind of difficult on a busy database, more so if it's a 24x7
environment. And
unfortunately there aren't any good alternatives either.
The difference between EXECUTE and SELECT behavior here is just a chance
matter of exactly where the snap is taken during the parse/execute code
path --- your SELECT works because it blocks for AccessShareLock on the
table before it sets the snap. But SELECT would fail just the same way
within a serializable transaction that had already set its snapshot.
Ok, makes sense. The same reasoning probably applies to INSERT and UPDATE as
well. Still the problem remains - how to cluster a table on a busy
system without losing
data or getting wrong results. Perhaps the issue should be documented,
although a fix
would be preferrable ;)
Martin
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
