On Sat, Mar 27, 2021 at 3:00 AM Noah Misch <
noah@leadboat.com> wrote:
>
> Does anyone have a strong opinion on whether to back-patch? I am weakly
> inclined not to back-patch, because today's behavior might happen to perform
> better when large_upd_rate-small_ins_rate<0.
It's not a clear case. The present behavior is clearly a bug, but only manifests in rare situations. The risk of the fix affecting other situations is not zero, as you mention, but (thinking briefly about this and I could be wrong) the consequences don't seem as big as the reported case of growing table size.
> Besides the usual choices of
> back-patching or not back-patching, we could back-patch with a stricter
> threshold. Suppose we accepted pages for larger-than-fillfactor tuples when
> the pages have at least
> BLCKSZ-SizeOfPageHeaderData-sizeof(ItemIdData)-MAXALIGN(MAXALIGN(SizeofHeapTupleHeader)+1)+1
> bytes of free space. That wouldn't reuse a page containing a one-column
> tuple, but it would reuse a page having up to eight line pointers.
I'm not sure how much that would help in the reported case that started this thread.
> Comments and the maxPaddedFsmRequest variable name use term "fsm" for things
> not specific to the FSM. For example, the patch's test case doesn't use the
> FSM. (That is fine. Ordinarily, RelationGetTargetBlock() furnishes its
> block. Under CLOBBER_CACHE_ALWAYS, the "try the last page" logic does so. An
> FSM-using test would contain a VACUUM.) I plan to commit the attached
> version; compared to v5, it updates comments and renames this variable.
Looks good to me, thanks!
--
John Naylor
EDB:
http://www.enterprisedb.com
