On Mon, Feb 4, 2019 at 8:47 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Feb 4, 2019 at 12:39 AM John Naylor <john.nay...@2ndquadrant.com> > wrote: > > > > On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila <amit.kapil...@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
