> 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
