Excerpts from Tom Lane's message of vie may 14 14:19:30 -0400 2010:
> The problem is that if any reloption is set for the toast table,
> we build a StdRdOptions struct in which fillfactor is zero, and
> then all the code that actually uses fillfactor honors that.
> And the reason fillfactor gets left as zero is that there is no
> entry for it in the tables for toast-table reloptions. Clearly,
> this wasn't thought through carefully enough.
Ouch :-( We messed with this stuff after the initial commit because I
didn't get it right the first time either. I'm surprised that we didn't
find this problem right away.
> I'm inclined to think that we should remove the notion of there
> being separate sets of rdoptions for heaps and toast tables ---
> any case in which someone tries to omit a StdRdOption for toast
> tables is going to fail the same way, unless we are fortunate
> enough that zero is a desirable default.
It doesn't seem like having the distinction has bought us anything.
However, if we do that, we can't add a separate entry to intRelOpts to
fix min/max/default to 100, so I think we should document that options
for toast must match those for heaps.
> What seems more rational is to provide toast.fillfactor but give it
> min/max/default = 100.
Adding an entry to intRelOpts should be enough to fix this bug, correct?
--