Обсуждение: BUG #7581: changing blocksize makes tests fail

The following bug has been logged on the website:

Bug reference:      7581
Logged by:          William Dauchy
Email address:      wdauchy@gmail.com
PostgreSQL version: 9.2.1
Operating system:   Linux
Description:        =


I tried to compile pgsql9.2 with the following options: --with-blocksize=3D=
16
and --with-wal-blocksize=3D16.

Some tests failed. I didn't have the issue with pgsql9.1.

Could someone confirm the issue?

select_views             ... FAILED
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 1 of 132 tests failed.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The differences that caused some tests to fail can be viewed in the
file
"/tmp/tmp.9mUS6kM8sm/postgresql-9.2-9.2.1/build/src/test/regress/regression=
.diffs".
 A copy of the test summary that you see
above is saved in the file
"/tmp/tmp.9mUS6kM8sm/postgresql-9.2-9.2.1/build/src/test/regress/regression=
.out".

make[2]: *** [bigcheck] Error 1
make[2]: Leaving directory
`/tmp/tmp.9mUS6kM8sm/postgresql-9.2-9.2.1/build/src/test/regress'
patching file src/test/regress/pg_regress.c
Hunk #1 succeeded at 898 (offset -8 lines).
Hunk #2 succeeded at 2201 (offset -6 lines).
Hunk #3 succeeded at 2233 (offset -6 lines).
patching file src/test/regress/pg_regress_main.c
patching file src/backend/main/main.c
patching file src/bin/initdb/initdb.c
patching file src/bin/pg_ctl/pg_ctl.c
Hunk #1 succeeded at 2006 (offset 9 lines).
********* regression.diffs *******
***
/tmp/tmp.9mUS6kM8sm/postgresql-9.2-9.2.1/build/../src/test/regress/expected=
/select_views.out
       Wed Sep 19 23:47:58 2012
---
/tmp/tmp.9mUS6kM8sm/postgresql-9.2-9.2.1/build/src/test/regress/results/sel=
ect_views.out
   Wed Oct  3 11:25:45 2012
***************
*** 1447,1457 ****
 =

---------------------------------------------------------------------------=
---------
   Subquery Scan on my_credit_card_usage_secure
     Filter: f_leak(my_credit_card_usage_secure.cnum)
!    ->  Nested Loop
!          Join Filter: (l.cid =3D r.cid)
           ->  Seq Scan on credit_usage r
                 Filter: ((ymd >=3D '10-01-2011'::date) AND (ymd <
'11-01-2011'::date))
!          ->  Materialize
                 ->  Hash Join
                       Hash Cond: (r.cid =3D l.cid)
                       ->  Seq Scan on credit_card r
--- 1447,1457 ----
 =

---------------------------------------------------------------------------=
---------
   Subquery Scan on my_credit_card_usage_secure
     Filter: f_leak(my_credit_card_usage_secure.cnum)
!    ->  Hash Join
!          Hash Cond: (r.cid =3D l.cid)
           ->  Seq Scan on credit_usage r
                 Filter: ((ymd >=3D '10-01-2011'::date) AND (ymd <
'11-01-2011'::date))
!          ->  Hash
                 ->  Hash Join
                       Hash Cond: (r.cid =3D l.cid)
                       ->  Seq Scan on credit_card r

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


-- =

William

wdauchy@gmail.com writes:
> I tried to compile pgsql9.2 with the following options: --with-blocksize=16
> and --with-wal-blocksize=16.
> Some tests failed. I didn't have the issue with pgsql9.1.

This is not a bug.  There are any number of changes you could make that
would affect either plan selection or row ordering (which usually means
the same thing) in the regression tests; block size is one, and there
are a lot of more-easily-varied GUC settings as well.  It was pure luck
if you didn't see such an issue in some specific prior release.

            regards, tom lane

Hello Tom,

Thank you for your reply,

On Wed, Oct 3, 2012 at 4:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This is not a bug.  There are any number of changes you could make that
> would affect either plan selection or row ordering (which usually means
> the same thing) in the regression tests; block size is one, and there
> are a lot of more-easily-varied GUC settings as well.  It was pure luck
> if you didn't see such an issue in some specific prior release.

didn't know about that; plus this is followed by lots of sql errors, I
was quite surprised to get zero error in 9.1 and so much in 9.2.

Thanks,
--
William