On 2018-02-18 11:18:49 -0500, Tom Lane wrote: > Joe Conway <m...@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
