BUG #7581: changing blocksize makes tests fail

Started by William Dauchyover 13 years ago3 messagesbugs
Jump to latest
#1William Dauchy
wdauchy@gmail.com

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=16
and --with-wal-blocksize=16.

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

Could someone confirm the issue?

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

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/select_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 = r.cid)
           ->  Seq Scan on credit_usage r
                 Filter: ((ymd >= '10-01-2011'::date) AND (ymd <
'11-01-2011'::date))
!          ->  Materialize
                 ->  Hash Join
                       Hash Cond: (r.cid = 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 = l.cid)
-> Seq Scan on credit_usage r
Filter: ((ymd >= '10-01-2011'::date) AND (ymd <
'11-01-2011'::date))
! -> Hash
-> Hash Join
Hash Cond: (r.cid = l.cid)
-> Seq Scan on credit_card r

======================================================================

--
William

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: William Dauchy (#1)
Re: BUG #7581: changing blocksize makes tests fail

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

#3William Dauchy
wdauchy@gmail.com
In reply to: Tom Lane (#2)
Re: BUG #7581: changing blocksize makes tests fail

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