On Sat, Mar 27, 2021 at 3:00 AM Noah Misch <n...@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
