On Mon, Jan 28, 2019 at 10:03 AM John Naylor
<john.nay...@2ndquadrant.com> wrote:
>
> On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
> > There are a few buildfarm failures due to this commit, see my email on
> > pgsql-committers. If you have time, you can also once look into
> > those.
>
> I didn't see anything in common with the configs of the failed
> members. None have a non-default BLCKSZ that I can see.
>
> Looking at this typical example from woodlouse:
>
> ================== pgsql.build/src/test/regress/regression.diffs
> ==================
> --- C:/buildfarm/buildenv/HEAD/pgsql.build/src/test/regress/expected/fsm.out
> 2019-01-28 04:43:09.031456700 +0100
> +++ C:/buildfarm/buildenv/HEAD/pgsql.build/src/test/regress/results/fsm.out
> 2019-01-28 05:06:20.351100400 +0100
> @@ -26,7 +26,7 @@
> pg_relation_size('fsm_check_size', 'fsm') AS fsm_size;
> heap_size | fsm_size
> -----------+----------
> - 24576 | 0
> + 32768 | 0
> (1 row)
>
> ***It seems like the relation extended when the new records should
> have gone into block 0.
>
> -- 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)
>
> ***And here it seems vacuum didn't truncate the FSM. I wonder if the
> heap didn't get truncated either.
>
Yeah, it seems to me that vacuum is not able to truncate the relation,
see my latest reply on another thread [1].
[1] -
https://www.postgresql.org/message-id/CAA4eK1JntHd7X6dLJVPGYV917HejjhbMKXn9m_RnnCE162LbLA%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
