Tom Lane wrote:
> I wrote:
> > Hmm, we could probably fix that if we made the cluster operation swap
> > the physical storage of the two toast tables, rather than swapping the
> > tables altogether. I agree it's not critical but it could be confusing.
>
> On second thought, I think it *could* lead to a visible failure.
> Suppose the OID counter wraps around and the OID that had been used for
> the temporary CLUSTER table gets assigned to a new table. If that table
> needs a toast table, it'll try to create one using the name that is
> already in use. We have defenses against picking an OID that's in use,
> but none for toast table names. So I think it's indeed worth fixing.
My first attempt at a fix, which was simply swapping relfilenode for the
TOAST tables (and its indexes) after the data has been copied, does not
work, apparently because the TOAST pointers have the toast table ID
embedded. Since we're intending to keep the pg_class entry for the old
TOAST table, the OID in the toast links is no longer valid.
I'm not sure what can be done about this ... Obviously we cannot just
swap the toast table before starting to move the data, because then we
cannot read the original data.
I wonder if we can get away with simply renaming the new toast table and
index after the data has been copied.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
