Обсуждение: gmake check runs just 13 tests instead of 77
Hi
I am testing the beta 5 version of 7.3, by using make check under solaris 7
and 8 and it runs just 13 tests as against 77 tests as indicated in the
README.regression, I dont get any errors on the screen:
/bin/sh ./pg_regress --temp-install --top-builddir=../../..
--schedule=./parallel_schedule --multibyte=SQL_ASCII
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 4772
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== dropping regression test user accounts ==============
============== installing PL/pgSQL ==============
============== running regression test queries ==============
parallel group (13 tests): text int2 boolean int8 float4 int4 char name
varchar oid float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
============== shutting down postmaster ==============
======================
All 13 tests passed.
======================
However I see the following errors in postmaster.log
LOG: database system was shut down at 2002-11-12 20:06:41 GMT
LOG: checkpoint record is at 0/849D78
LOG: redo record is at 0/849D78; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 480; next oid: 16976
LOG: database system is ready
ERROR: DROP GROUP: group "regressgroup1" does not exist
ERROR: pg_atoi: error in "34.5": can't parse ".5"
ERROR: pg_atoi: error reading "100000": Numerical result out of range
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
ERROR: value too long for type character(1)
ERROR: Bad boolean external representation 'XXX'
ERROR: value too long for type character varying(1)
ERROR: oidin: error in "asdfasd": can't parse "asdfasd"
ERROR: oidin: error in "99asdfasd": can't parse "asdfasd"
ERROR: value too long for type character(4)
ERROR: value too long for type character varying(4)
ERROR: pg_atoi: error in "34.5": can't parse ".5"
ERROR: pg_atoi: error reading "1000000000000": Numerical result out of
range
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
ERROR: Bad float4 input format -- overflow
ERROR: Bad float4 input format -- overflow
ERROR: Bad float4 input format -- underflow
ERROR: Bad float4 input format -- underflow
ERROR: Bit string length 2 does not match type BIT(11)
ERROR: Bit string length 12 does not match type BIT(11)
ERROR: float4div: divide by zero error
ERROR: Bit string too long for type BIT VARYING(11)
ERROR: Bad float8 input format -- overflow
ERROR: pow() result is out of range
ERROR: can't take log of zero
ERROR: can't take log of a negative number
ERROR: exp() result is out of range
ERROR: float8div: divide by zero error
ERROR: Input '10e400' is out of range for float8
ERROR: Input '-10e400' is out of range for float8
ERROR: Input '10e-400' is out of range for float8
ERROR: Input '-10e-400' is out of range for float8
ERROR: Cannot AND bit strings of different sizes
ERROR: Cannot OR bit strings of different sizes
ERROR: Cannot XOR bit strings of different sizes
ERROR: overflow on numeric ABS(value) >= 10^0 for field with precision 4
scale 4
ERROR: overflow on numeric ABS(value) >= 10^0 for field with precision 4
scale 4
LOG: smart shutdown request
LOG: shutting down
Please comment
Thanks
Khat
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
"Mr OCP" <mr_ocp@hotmail.com> writes:
> I am testing the beta 5 version of 7.3, by using make check under solaris 7
> and 8 and it runs just 13 tests as against 77 tests as indicated in the
> README.regression,
Hmm, maybe a portability problem in the pg_regress script ... but I
thought we'd already checked 7.3 on Solaris. Andrew, can you reproduce
this problem?
regards, tom lane
Tom Lane wrote:
> "Mr OCP" <mr_ocp@hotmail.com> writes:
> > I am testing the beta 5 version of 7.3, by using make check under solaris 7
> > and 8 and it runs just 13 tests as against 77 tests as indicated in the
> > README.regression,
>
> Hmm, maybe a portability problem in the pg_regress script ... but I
> thought we'd already checked 7.3 on Solaris. Andrew, can you reproduce
> this problem?
It does report:
All 13 tests passed.
I wonder if Solaris folks are thinking that is a success. I see you
found that my awk 'BEGIN ...' was the problem. I didn't realize awk
would do that. On BSD/OS using gawk, it is OK:
$ echo "1\n2" | while read FILE; do echo $FILE;awk 'BEGIN {print "a"}';
done
1
a
2
a
Anyway, pg_regress.sh should just be fixed. I added this code so I
didn't have to do gymnatics on echoing a backslash:
echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}'; cat "$inputdir/sql/$name.sql") |
I didn't use this method in any of my other autocommit fixes. I did it
this way only so I could turn autocommit on without having it show up in
the regression output.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Tue, Nov 12, 2002 at 03:55:55PM -0500, Tom Lane wrote:
>
> Hmm, maybe a portability problem in the pg_regress script ... but I
> thought we'd already checked 7.3 on Solaris. Andrew, can you reproduce
> this problem?
It worked for me in the last beta; but someone reported the same
problem to me today on our boxes here, so something is fishy.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
Andrew Sullivan wrote:
> On Tue, Nov 12, 2002 at 03:55:55PM -0500, Tom Lane wrote:
> >
> > Hmm, maybe a portability problem in the pg_regress script ... but I
> > thought we'd already checked 7.3 on Solaris. Andrew, can you reproduce
> > this problem?
>
> It worked for me in the last beta; but someone reported the same
> problem to me today on our boxes here, so something is fishy.
I show the 'awk' added by me on October 19th, actually to get
postgresql.conf 'autocommit off' working for regression tests:
revision 1.28
date: 2002/10/19 01:35:43; author: momjian; state: Exp; lines: +10 -5
Make regression tests safe for autocommit = 'off'.
Did it work after that date?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hi I have just downloaded and installed PgSQL 7.3b5. Unfortunately the same problem is still there. There is no way to diallow creating tables in the database. Every user is able to crete tables in every database. So there is no much sence to disallow users to create schemas when they can create tables. in fact the same security problem remains if someone wants to fill your database (respectively filesystem) with bulk. I have waited for this feature since v 6.5 but I am very dissaopinted. Is this the new security ?!? SO WILL THERE EVER BE POSSIBLE TO DISALLOW OBJECT CREATION TO USERS AND TO GIVE THEM ONLY READ ACCESS TO SOME OBJECTS IN A DB? 10x a lot! Hal __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
On Tue, Nov 12, 2002 at 10:17:25PM -0500, Bruce Momjian wrote:
> I show the 'awk' added by me on October 19th, actually to get
> postgresql.conf 'autocommit off' working for regression tests:
>
> revision 1.28
> date: 2002/10/19 01:35:43; author: momjian; state: Exp; lines: +10 -5
> Make regression tests safe for autocommit = 'off'.
>
> Did it work after that date?
According to my report, yes. I tested 7.3b3 on 2002-10-28.
I'll bet it had to do with a funky path I had, though; probably I
picked up a different awk (there are two on Solaris), because I was
also working on another problem during the same period. (I can try
out this theory today, if I'm lucky enough to get a minute or two.)
Bad dba! Test in a clean environment! I apologise.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
Heni Lolov <hal_bg@yahoo.com> writes:
> SO WILL THERE EVER BE POSSIBLE TO DISALLOW
> OBJECT CREATION TO USERS AND TO GIVE THEM
> ONLY READ ACCESS TO SOME OBJECTS IN A DB?
If you'd quit shouting and RTFM, you'd find out that it's possible in
7.3. (Hint: drop the public schema or revoke privileges on it.)
regards, tom lane
Sorry :) forgive me please! ive tried : revoke all ON schema public from hal; but does not work. Why? with drop it worked :) Ive got : ERROR: No namespace has been selected to create in regards, hal --- Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heni Lolov <hal_bg@yahoo.com> writes: > > SO WILL THERE EVER BE POSSIBLE TO DISALLOW > > OBJECT CREATION TO USERS AND TO GIVE THEM > > ONLY READ ACCESS TO SOME OBJECTS IN A DB? > > If you'd quit shouting and RTFM, you'd find out that it's possible in > 7.3. (Hint: drop the public schema or revoke privileges on it.) > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
>From: Andrew Sullivan <andrew@libertyrms.info> > >According to my report, yes. I tested 7.3b3 on 2002-10-28. > >I'll bet it had to do with a funky path I had, though; probably I >picked up a different awk (there are two on Solaris), because I was >also working on another problem during the same period. (I can try >out this theory today, if I'm lucky enough to get a minute or two.) >Bad dba! Test in a clean environment! I apologise. With nawk it works fine and does all 89 tests : ============== shutting down postmaster ============== ====================== All 89 tests passed. ====================== _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
"Mr OCP" <mr_ocp@hotmail.com> writes:
> I am testing the beta 5 version of 7.3, by using make check under solaris 7
> and 8 and it runs just 13 tests as against 77 tests as indicated in the
> README.regression,
I believe this problem is now fixed --- the pg_regress script was
making an unportable assumption about the behavior of 'awk'. If you
want to try it, apply the attached patch.
regards, tom lane
*** src/test/regress/pg_regress.sh.orig Sat Oct 19 13:30:30 2002
--- src/test/regress/pg_regress.sh Wed Nov 13 11:40:23 2002
***************
*** 545,560 ****
formatted=`echo $1 | awk '{printf "%-20.20s", $1;}'`
$ECHO_N "test $formatted ... $ECHO_C"
! # use awk to properly output backslashes
! (echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}'; cat "$inputdir/sql/$1.sql") |
$PSQL -d "$dbname" >"$outputdir/results/$1.out" 2>&1
else
# Start a parallel group
$ECHO_N "parallel group ($# tests): $ECHO_C"
for name do
(
! # use awk to properly output backslashes
! (echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}'; cat
"$inputdir/sql/$name.sql")|
$PSQL -d $dbname >"$outputdir/results/$name.out" 2>&1
$ECHO_N " $name$ECHO_C"
) &
--- 545,566 ----
formatted=`echo $1 | awk '{printf "%-20.20s", $1;}'`
$ECHO_N "test $formatted ... $ECHO_C"
! (cat <<EOF
! SET autocommit TO 'on';
! \\set ECHO all
! EOF
! cat "$inputdir/sql/$1.sql") | \
$PSQL -d "$dbname" >"$outputdir/results/$1.out" 2>&1
else
# Start a parallel group
$ECHO_N "parallel group ($# tests): $ECHO_C"
for name do
(
! (cat <<EOF
! SET autocommit TO 'on';
! \\set ECHO all
! EOF
! cat "$inputdir/sql/$name.sql") | \
$PSQL -d $dbname >"$outputdir/results/$name.out" 2>&1
$ECHO_N " $name$ECHO_C"
) &
Heni Lolov <hal_bg@yahoo.com> writes:
> ive tried :
> revoke all ON schema public from hal;
> but does not work. Why?
You'd need to revoke the permissions from PUBLIC; they were never granted
specifically to hal, thus the above revoke is a no-op.
Don't forget to revoke CREATE at the database level, too, else a user
can just create his own schema. Perhaps also revoke TEMP, depending on
whether you'd like to forbid temporary tables as well.
In short, something like
revoke create on schema public from public;
revoke create,temp on database mydb from public;
should give you a database in which users can't create anything.
regards, tom lane
On Wed, Nov 13, 2002 at 07:56:38AM -0500, Andrew Sullivan wrote:
> I'll bet it had to do with a funky path I had, though; probably I
> picked up a different awk (there are two on Solaris), because I was
> also working on another problem during the same period. (I can try
For the record, I did confirm this, and it's what happened. It's
needless now, of course, because of the patched regression test.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
I am having an optimization problem with queries that include IN clauses
and subselects.
xxx=> select version();
version
-------------------------------------------------------------
PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96
The basic query I have is:
UPDATE my_table
SET some_col=some_value
WHERE my_table.foreign_key_with_an_index IN (
SELECT primary_key
FROM my_other_table
WHERE my_other_table.some_indexed_column = some_other_value);
The problem is that even though <my_table> has an index on
<my_table.foreign_key_with_an_index>, an EXPLAIN reports and performance
supports the fact that the server performs a sequential scan on my_table
instead of an indexed scan on the column. This is in contrast to the
query:
UPDATE my_table
SET some_col=some_value
WHERE my_table.foreign_key_with_an_index IN (val1,val2,val3...)
which will show an indexed scan and accordingly good performance.
Having done digging within the online user docs, including
http://www.ca.postgresql.org/docs/faq-english.html#4.22, I'm not sure
whether this is an issue of Postgres always wanting to seq_scan when faced
with IN clauses and subselects or if I have a stats problem where the
optimizer thinks my subselect will return hundreds of rows (even though I
know it's never more than 4) and thus opts for a single seq rather than
100s of random page accesses to go from index to base table.
If it is the former, then I've got an issue with the optimizers
capabilibilities and will be looking for info that something within a later
release will makes things better.
If it is the latter, I need to continue my learning journey into the
optimizer, Analyze and statistics.
Can someone shed light as to which path I should be following?
Marc Mitchell - Senior Application Architect
Enterprise Information Solutions, Inc.
Downers Grove, IL 60515
marcm@eisolution.com
"Marc Mitchell" <marcm@eisolution.com> writes:
> I am having an optimization problem with queries that include IN clauses
> and subselects.
The optimizer currently has no clue at all about dealing with
"IN (subselect)", and always converts it into the worst sort of
nested-loop plan. I'm hoping to do something about that for 7.4, but
it's only pie-in-the-sky today. In the meantime, the conventional
wisdom is to convert your query into an EXISTS() test instead of an IN()
test. This is still nested-loop, but not as bad --- the clause you push
down into the EXISTS() has a shot at using an index. I believe the
details are in the FAQ.
regards, tom lane