Re: Add pg_freespacemap extension sql test

On Mon, Mar 21, 2022 at 09:12:37PM +0900, Dong Wook Lee wrote:
> 2022년 3월 20일 (일) 03:13, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>님이
> 작성:
>> On Sat, Mar 19, 2022 at 1:18 PM Dong Wook Lee <sh95119(at)gmail(dot)com> wrote:
>>>> Well, my guess is that you basically just care about being able to
>>>> detect if there is free space in the map or not, which goes down to
>>>> detecting if pg_freespace() returns 0 or a number strictly higher than
>>>> 0, so wouldn't it be enough to stick some > 0 in your test queries?
>>>
>>> I edited the previous patch file.
>>> Am I correct in understanding that?
>>>
>>
>> I think what Michael meant is something like attached.
>
> I think you’re right, thank you for sending it instead of me.

Yes, something like v3 was what I was referring to as we cannot rely
on exact numbers for this test suite. At least, we can check if there
is a FSM for a given block, even if that can be limited.

After review, I don't like much the idea of allowing concurrent
autovacuums to run in parallel of the table(s) of this test, so we'd
better disable it explicitely. "t1" is also a very generic name to
use in a regression test. Another thing that itched me is that we
could also test more with indexes, particularly with btree, BRIN and
hash (the latter should not have a FSM with 10 pages as per the first
group batch, and each one has a stable an initial state). Finally,
making the tests stable across 32-bit compilations (say gcc -m32) is
proving to be tricky, but it should be safe enough to check if the FSM
is computed or not with a minimal number of tuples.

Btw, a .gitignore was also forgotten.

I have extended the set of tests as of the attached, running these
across everything I could (CI, all my hosts including Windows, macos,
Linux). We could do more later, of course, but this looks enough to
me as a first step. And I think that this will not upset the
buildfarm.
--
Michael