Re: [ADMIN] security - user account setup on SUSE

2005-05-12 Thread Ivo Rossacher
Am Mittwoch, 11. Mai 2005 20:42 schrieb Brandon Fouts: > I think for security reasons I should not run PostgreSQL from the root yes. > account. Also, as PostgreSQL will probably be only one of the applications > running on this box. (would running in UML give me any extra security? - I > suspect

Re: [ADMIN] brute force attacking the password

2005-05-12 Thread Bruno Wolff III
On Thu, May 12, 2005 at 00:23:05 +0200, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * Bruno Wolff III <[EMAIL PROTECTED]> wrote: > > > Maybe you can use client side certificates. > > how can they be used w/ psql ? You should be able to get PAM to do this, but I haven't tried it to make sure.

[ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
When joining two tables the query plan is doing a seq scan rather than index scan. I do have indexes on the columns used for joining the tables. Example: SELECT a.id FROM a, b WHERE a.id = b.id; QUERY PLAN

Re: [ADMIN] how do i kill user sessions?

2005-05-12 Thread Scott Marlowe
On Wed, 2005-05-11 at 17:49, Chris Browne wrote: > [EMAIL PROTECTED] (Scott Marlowe) writes: > > > On Wed, 2005-05-11 at 15:08, Ing. Jhon Carrillo wrote: > >> I have a problem with the users administration. When I want to erase > >> (drop) some databases there's an error: ** database "name_db" is

Re: [ADMIN] memory allocation ; postgresql-8.0

2005-05-12 Thread Kavan, Dan (IMS)
Hi Scott, Thanks again for all your tips. If I knock the buffer size down to 65,536 (still higher than what you are recommending) then my shmmax becomes: 256,000 + 550,292,685 (65536*8396.8) + 1,454,100 = 552,002,785 That will leave me with 3.5 GB of free memory for the system & work memory

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Tom Lane
Prasanth <[EMAIL PROTECTED]> writes: > Hash Join (cost=13865.30..326413.23 rows=6451 width=18) >Hash Cond: ("outer".id = "inner".id) >-> Seq Scan on a (cost=0.00..125076.37 rows=6450937 width=18) >-> Hash (cost=10168.64..10168.64 rows=500664 width=4) > -> Seq Scan on b (

Re: [ADMIN] memory allocation ; postgresql-8.0

2005-05-12 Thread Scott Marlowe
On Thu, 2005-05-12 at 10:10, Kavan, Dan (IMS) wrote: > Hi Scott, > > Thanks again for all your tips. > > If I knock the buffer size down to 65,536 (still higher than what you > are recommending) then my shmmax becomes: > 256,000 + 550,292,685 (65536*8396.8) + 1,454,100 = 552,002,785 > > That

[ADMIN] Help with connections

2005-05-12 Thread Gourish Singbal
Guys i need some help. Initially the connections to the database were 3 as seen using netstat -a -n | grep "ESTAB" | grep and ps -ef | grep postgres After some time the connections suddenly incresed to 53 using the above commands. if i do /usr/local/pgsql/bin/psql -d -c "select c.relname,d.d

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Scott Marlowe
On Thu, 2005-05-12 at 10:05, Prasanth wrote: > When joining two tables the query plan is doing a seq scan rather than index > scan. I do have indexes on the columns used for joining the tables. > > Example: > SELECT a.id FROM a, b WHERE a.id = b.id; > >QUER

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
Thanks for the prompt reply. Table a has about 6 million and table b had a little more than half a million. Sorry I wasn't exact about my numbers before. I will be having the where conditions on both the tables that would bring down the count drastically. Even in this case the planner is going f

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Scott Marlowe
On Thu, 2005-05-12 at 10:51, Prasanth wrote: > I agree with you. > > But I have the where conditions on the tables I was expecting the planner to > user index scan but it went for seq scan. > > I did a little testing using what you said. > > Below are the results. > > SELECT a.id FROM a,b WHERE

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
I agree with you. But I have the where conditions on the tables I was expecting the planner to user index scan but it went for seq scan. I did a little testing using what you said. Below are the results. SELECT a.id FROM a,b WHERE a.id = b.id AND a.code >2 AND b.account_id = 16221; Total runti

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Tom Lane
Prasanth <[EMAIL PROTECTED]> writes: > A where condition I always use is shown below. This is bringing down the > number > of rows from 6.5m to 1210. I have an index on code also. Even here it is going > for seq scan. > EXPLAIN ANALYZE SELECT count(*) fROM a where Code >2; >

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
EXPLAIN ANALYZE (SELECT id FROM a,b WHERE a.id = b.id AND code >2 AND b.account_id = 16221); QUERY PLAN --- Merge Joi

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
code data type is int2. I am sorry that I did not mention the version number I am using 7.4.7. Thanks, -Prasanth. Tom Lane wrote: > Prasanth <[EMAIL PROTECTED]> writes: > >>A where condition I always use is shown below. This is bringing down the >>number >>of rows from 6.5m to 1210. I have an

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Tom Lane
Prasanth <[EMAIL PROTECTED]> writes: > code data type is int2. Ah-hah. So "where code > 2::int2" should work noticeably better for you. Or you could do "where code > '2'" to avoid hard-wiring the data type knowledge into your queries. Or just change it to int4 ;-) Or update to 8.0.

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
Sorry seems like I am missing some thing here. What is the difference between int2 & int4 as far as index scan is concerned? I did try to update to 8.0 but it is not taking my dump from 7.4.7. If I remember right it was complaining about pg_database being not present. I posted a message on forums

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
Thanks Tom. Seems like having int2 after code is doing the trick. Can you please explain the reasons behind this. I Really appreciate your time. Thanks, -Prasanth. Tom Lane wrote: > Prasanth <[EMAIL PROTECTED]> writes: > >>code data type is int2. > > > Ah-hah. So "where code > 2::int2" sho

[ADMIN] Compile Error for postgresql-8.0.3

2005-05-12 Thread Vishal Kashyap @ [SaiHertz]
Dear all , Got compile error for postgresql-8.0.3 error is following gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition -Wendif-labels -fno-strict-aliasing -Wno-error -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I./../i

Re: [ADMIN] memory allocation ; postgresql-8.0

2005-05-12 Thread Kavan, Dan (IMS)
Do psql calls/procedures access resources reserved from the kernel.shmmax? How about the tar or copy sysadmin commands? I would guess they don't use kernel.shmmax resources. Finally, work memory alos does not access resources reserved from kernel.shmmax, correct? Thanks for clearing things up.

Re: [ADMIN] resource allocation ; postgresql-8.0

2005-05-12 Thread Kavan, Dan (IMS)
Scott, If you had two applications that were each connecting to two different databases, have you found that it's beneficial to have to different instances of postgres running? I have a few reasons why I think it would be better. One, it would be beneficial to customize parameters for each appl

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Prasanth
Ok read about the indexes and type matches. So is this fixed in 8.0? Thanks, -Prasanth. Tom Lane wrote: > Prasanth <[EMAIL PROTECTED]> writes: > >>code data type is int2. > > > Ah-hah. So "where code > 2::int2" should work noticeably better for > you. Or you could do "where code > '2'" to a

Re: [ADMIN] memory allocation ; postgresql-8.0

2005-05-12 Thread Scott Marlowe
On Thu, 2005-05-12 at 12:46, Kavan, Dan (IMS) wrote: > Do psql calls/procedures access resources reserved from the > kernel.shmmax? Only in the sense that it can execute a query, which in the backend could therefore use shared memory. psql, itself, doesn't use shared memory. > How about the tar

Re: [ADMIN] Query Plan - Index Scan & Seq Scan

2005-05-12 Thread Tom Lane
Prasanth <[EMAIL PROTECTED]> writes: > Seems like having int2 after code is doing the trick. > Can you please explain the reasons behind this. When you write "int2col > 2", the operator that is selected is int2-gt-int4. However the index on an int2 column can only deal with int2-gt-int2. 8.0 gene

Re: [ADMIN] Compile Error for postgresql-8.0.3

2005-05-12 Thread Tom Lane
"Vishal Kashyap @ [SaiHertz]" <[EMAIL PROTECTED]> writes: > In file included from preproc.y:6409: > pgc.l: In function `yylex': > pgc.l:920: error: `xsoip' undeclared (first use in this function) Corrupted download maybe? That line refers to "xskip" not "xsoip". regards,

Re: [ADMIN] resource allocation ; postgresql-8.0

2005-05-12 Thread Scott Marlowe
On Thu, 2005-05-12 at 12:56, Kavan, Dan (IMS) wrote: > Scott, > If you had two applications that were each connecting to two different > databases, have you found that it's beneficial to have to different > instances of postgres running? I haven't, but I could see where, if the workloads were ve

[ADMIN] catastrophic error

2005-05-12 Thread Joel Fradkin
Hi,   I have been live for 4 days (vacuums run each night and backups done each night). Today around 2:30 PM  EST my web app returned a catastrophic error. Both web servers appeared to have the issue. I could go on them and get data via pgadmin. I could log on the server (IIS servers

Re: [ADMIN] catastrophic error

2005-05-12 Thread Matthew T. O'Connor
If you could connect to the database server from the web server and get data with PGAdmin then it doesn't' sound like a database or database server problem. How is your web app connecting to the database? ODBC? That might be a bit of an issue. PgAdmin doesn't use ODBC, it uses libpq directl

Re: [ADMIN] catastrophic error

2005-05-12 Thread Bricklen Anderson
Joel Fradkin wrote: Hi, I have been live for 4 days (vacuums run each night and backups done each night). Today around 2:30 PM EST my web app returned a catastrophic error. Both web servers appeared to have the issue. I could go on them and get data via pgadmin. I could log on the server (IIS

[ADMIN] ACT! and PostgreSQL

2005-05-12 Thread Postgres Admin
I have some clients that are looking to upgrade to MSSQL Server because they use ACT!. I'm developing a web application for them that uses PostgreSQL. Does anyone know if ACT! can use PostgreSQL? or if I can hack it? Suggestion welcome and Thanks, J ---(end of broadcas

Re: [ADMIN] ACT! and PostgreSQL

2005-05-12 Thread Goulet, Dick
Looks like you've tied into one of those Microsoft clone companies that can't get off the Microslop stack. Have a similar problem with a product here that will not work with anything other than Sql*slave and if you hack it they won't support it. Best of luck. It also looks like one of those "sm

Re: [ADMIN] catastrophic error

2005-05-12 Thread Joel Fradkin
The catastrophic error was the actual text sent from the IIS component error. SO I am not 100% sure what it means, I believe it is just mirroring back text from the dbserver when trying to connect and failing. I am guessing it is odbc and I am currently using the 7.4 version, but am looking for t

Re: [ODBC] [ADMIN] catastrophic error

2005-05-12 Thread Marko Ristola
About ASCII to Unicode conversion (if you have only Latin1 characters in the database): Here is a receipt, how you can do a charset conversion from SQL_ASCII into UNICODE on the Linux side: (check these from manual pages first!): 1. Stop PostgreSQL and make a good backup! "su - postgres" ; "pg_du

[ADMIN] using greater than or less than vs equals in where condition

2005-05-12 Thread Prasanth
PG Version: 7.4.7 OS: RedHat FC3 Below are two queries that would give the same results but amount of execution time is so different. explain analyze select * from data where type_code >'2' AND type_code<'4'; QUERY PLAN

Re: [ADMIN] using greater than or less than vs equals in where condition

2005-05-12 Thread Tom Lane
Prasanth <[EMAIL PROTECTED]> writes: > PG Version: 7.4.7 > explain analyze select * from data where type_code >'2' AND type_code<'4'; > [ is slow ] > explain analyze select * from data where type_code = '3'; > [ isn't ] Are there a whole lot of rows with type_code = 2? If so, this is fixed in 8.