Re: pgsql: Avoid creation of the free space map for small heap relations. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pgsql: Avoid creation of the free space map for small heap relations.
Date
Msg-id CAA4eK1JntHd7X6dLJVPGYV917HejjhbMKXn9m_RnnCE162LbLA@mail.gmail.com
Whole thread Raw
Responses Re: pgsql: Avoid creation of the free space map for small heap relations.
Re: pgsql: Avoid creation of the free space map for small heap relations.
List pgsql-hackers
On Mon, Jan 28, 2019 at 8:49 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jan 28, 2019 at 8:17 AM Amit Kapila <akapila@postgresql.org> wrote:
> >
> > Avoid creation of the free space map for small heap relations.
> >
>
> It seems there is some failure due to this on build farm machines. I
> will investigate!
>

The failure is as below:

@@ -26,7 +26,7 @@
 pg_relation_size('fsm_check_size', 'fsm') AS fsm_size;
  heap_size | fsm_size
 -----------+----------
-     24576 |        0
+     32768 |        0
 (1 row)

 -- Extend table with enough blocks to exceed the FSM threshold
@@ -56,7 +56,7 @@
 SELECT pg_relation_size('fsm_check_size', 'fsm') AS fsm_size;
  fsm_size
 ----------
-    16384
+    24576
 (1 row)

So here in the above tests, we are deleting some rows, performing
vacuum and then checking the size of heap and or vacuum.  It seems to
me sometimes the vacuum is *not* able to remove the rows and truncate
the relation/FSM as per tests expectation.  One possible theory is
that there is some parallel transaction running which prevents a
vacuum from doing so.  We have tried to avoid that by not allowing to
run the FSM test in parallel with other tests, but I think still
something seems to have run in parallel to the FSM test.  One
possibility is that autovacuum has triggered to perform truncation of
some other relation (remove pages at the end) which doesn't allow the
FSM test to remove the rows/perform truncation and thus let to the
failure.  Can there be anything else which can start a transaction
when a regression test is running?  Still thinking, but inputs are
welcome.

If my theory is correct, then in the newly added tests by this patch,
we can't rely on the vacuum to truncate the relation pages at the end
and hence can't rely on heap/FSM size.

Thoughts?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [Sender Address Forgery]Re: using expression syntax for partitionbounds
Next
From: David Rowley
Date:
Subject: Re: speeding up planning with partitions