On Thu, Jan 31, 2019 at 9:18 PM John Naylor <john.naylor@2ndquadrant.com> wrote:
>
> On Thu, Jan 31, 2019 at 4:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I don't think that moving fsm tests to brin would be a good approach.
> > We want to have a separate test for each access method. I think if we
> > want to do something to avoid portability issues, maybe we can do what
> > Masahiko San has just suggested.
>
> We could also use the same plpgsql loop as in fsm.sql to check the ctid, right?
>
Yes, however, I feel we should leave it as it is for now unless we see
any risk of portability issues. The only reason to do that way is to
avoid any failure for bigger block size (say BLCKSZ is 16KB or 32KB).
Does anyone else have any opinion on whether we should try to write
tests which should care for bigger block size? I see that existing
regression tests fail if we configure with bigger block size, so not
sure if we should try to avoid that here. In an ideal scenario, I
think it would be good if we can write tests which pass on all kind of
block sizes, that will make the life easier if tomorrow one wants to
set up a buildfarm or do the testing for bigger block sizes.
> > OTOH, I think we are just good w.r.t
> > this issue with the last patch I sent. I think unless we see some
> > problem here, we should put energy into having a reproducible test for
> > the fourth problem mentioned in my mail up thread [1]. Do you think
> > it makes sense to run make check in loop for multiple times or do you
> > have any idea how we can have a reproducible test?
>
> Okay. Earlier I tried running make installcheck with
> force_parallel_mode='regress', but didn't get a failure.
>
AFAICS, this failure was not for force_parallel_mode='regress'. See
the config at [1].
> I may not
> have run enough times, though.
>
Yeah, probably running make check or make installcheck many times
would help, but not sure.
> I'll have to think about how to induce
> it.
>
Thanks!
[1] - https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-28%2004%3A00%3A23
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com