On Mon, Feb 4, 2019 at 8:47 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Feb 4, 2019 at 12:39 AM John Naylor <john.naylor@2ndquadrant.com> wrote:
> >
> > On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > This doesn't get applied cleanly after recent commit 0d1fe9f74e.
> > > Attached is a rebased version. I have checked once that the changes
> > > done by 0d1fe9f74e don't impact this patch. John, see if you can also
> > > once confirm whether the recent commit (0d1fe9f74e) has any impact. I
> > > am planning to push this tomorrow morning (IST) unless you or anyone
> > > see any problem with this.
> >
> > Since that commit changes RelationAddExtraBlocks(), which can be
> > induces by your pgbench adjustment upthread, I ran make check with
> > that adjustment in the pgbench dir 300 times without triggering
> > asserts.
> >
> > I also tried to follow the logic in 0d1fe9f74e, and I believe it will
> > be correct without a FSM.
> >
>
> I have just pushed it and buildfarm has shown two failures:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2019-02-04%2002%3A27%3A26
>
> --- /Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/expected/page.out
> 2019-02-03 21:27:29.000000000 -0500
> +++ /Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/results/page.out
> 2019-02-03 21:41:32.000000000 -0500
> @@ -38,19 +38,19 @@
> SELECT * FROM fsm_page_contents(get_raw_page('test_rel_forks', 'fsm', 0));
> fsm_page_contents
> -------------------
> - 0: 39 +
> - 1: 39 +
> - 3: 39 +
> - 7: 39 +
> - 15: 39 +
> - 31: 39 +
> - 63: 39 +
> ..
>
> This one seems to be FSM test portability issue (due to different page
> contents, maybe). Looking into it, John, see if you are around and
> have some thoughts on it.
>
One more similar failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2019-02-04%2003%3A20%3A01
So, basically, this is due to difference in the number of tuples that
can fit on a page. The freespace in FSM for the page is shown
different because of available space on a particular page. This can
vary due to alignment. It seems to me we can't rely on FSM contents
if there are many tuples in a relation. One idea is to get rid of
dependency on FSM contents in this test, can you think of any better
way to have consistent FSM contents across different platforms?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com