On 2018-02-18 11:18:49 -0500, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Is there really a compelling reason to not just create toast tables for
> > all system catalogs as in the attached?
>
> What happens when you VACUUM FULL pg_class? (The associated toast table
> would have to be nonempty for the test to prove much.)
>
> I'm fairly suspicious of toasting anything that the toast mechanism itself
> depends on, actually, and that would include at least pg_attribute and
> pg_index as well as pg_class. Maybe we could get away with it because
> there would never be any actual recursion only potential recursion ...
> but it seems scary.
>
> On the whole, I'm dubious that the risk/reward ratio is attractive here.
I think we should just review the code to make sure bootstrapping works
for pg_class and fix if necessary. We've discussed this repeatedly, and
this concern has been the blocker every time - at this point I'm fairly
sure we could have easily fixed the issues.
At least the simpler case, where the bootstrapped contents themselves
aren't toasted, shouldn't be hard to support. And that restriction seems
fairly easy to support, by dint of the population mechanism for
bootstrapped catalogs not supporting toasting.
What I'm not sure will work correctly without fixes is the relation
swapping logic for VACUUM FULL / CLUSTER. There's some pg_class specific
logic in there, that might need to be adapted for pg_class's toast
table.
Greetings,
Andres Freund