[ADMIN] postgresql and apache slow down
hi guys, I'm preparing a new server to host some website postgresql+php4+apache 1.3.x based. the machine's hardware configuration is: * amd sempron 3200+ native 64bit * 1 GB ram DDR2 * chipset nvidia geforce 6100 * controller sata2 silicon image 3112 with RAID functionality * 2 sata2 hard disk western digital the machine's software configuration is: *debian etch 4.0 last snapshot * apache 1.3.34 * php 4-4-4 * php4 pgsql connector * postgresql 8.2.1 compiled from source The machine is on my LAN 100 Mbps. I've put a simple drupal site 4.7.x for benchmark purposes. trying for another machine (but from the same too) ab with concurrency 50 and 2000 requests I got an enormous RAM consunption from apache and postgres processes. The machine begin to swap heavily and the only solution is to stop apache and postgresql processes to regain the control of it. The same test on my production machine (debian sarge 3.1, postgresql 8.1.6 from source) don't have problem. What can be the cause of this crazy behaviour? Best Regards Federico Campoli ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Can not connect to database in Workgroup-Net on Windows-XP
I can understand the exact error as its not in english :) but it seems like an authentication problem. Please change 'md5' to 'trust' in pg_hba.conf file and then use: pg_ctl -D reload That will reload the settings for authentication. Now once the settings are reloaded try reconnecting to the database and it should go fine this time Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/15/07, Josef Springer <[EMAIL PROTECTED]> wrote: Hi folks, i have a workgroup (not a classic server) with Windows-XP-machines: the database server machine contains the line *host allall 0.0.0.0 0.0.0.0md5* in the file pg_hba.conf and *listen_addresses = '*' * in the file postgresql.conf. The clients' host file contain the line *nnn.nnn.nnn.nnn Labor* where nnn.nnn.nnn. is the IP-adress of the database server machine and /Labor /is the machine's name. If i start PGAdmin III on the 'client' machine i can not connect to the database on the machine Labor no matter wether i use the machine's name or the IP-adress. Instead i get the message * "Zum Server ist keine Verbindung möglich, * * oder Login/Passwort sind falsch.* * Die Anmeldung wurde abgelehnt."* Please help me. What to do ? mit freundlichen Grüßen / best regards, Josef Springer (Geschäftsleitung/Management) [image: Postal] Address [EMAIL PROTECTED] Orlando-di-Lasso Str. 2 D-85640 Putzbrunn [image: Phone] Office +49 (0)89 600 6920 [image: Phone] Fax +49 (0)89 600 69220 [image: Web] Web http://www.joops.com [image: JOOPS] *-- the software company --*
Re: [ADMIN] Can not connect to database in Workgroup-Net on Windows-XP
Title: Signature Hi Mir, thanks for your quick answer. We will try this. For my unterstanding: Why should i use trust instead of md5 ? A configuration at another customer (with a domain setting) using md5 works fine ? mit freundlichen Grüßen / best regards, Josef Springer (Geschäftsleitung/Management) Address [EMAIL PROTECTED] Orlando-di-Lasso Str. 2 D-85640 Putzbrunn Office +49 (0)89 600 6920 Fax +49 (0)89 600 69220 Web http://www.joops.com -- the software company -- Shoaib Mir wrote: I can understand the exact error as its not in english :) but it seems like an authentication problem. Please change 'md5' to 'trust' in pg_hba.conf file and then use: pg_ctl -D reload That will reload the settings for authentication. Now once the settings are reloaded try reconnecting to the database and it should go fine this time Shoaib Mir EnterpriseDB ( www.enterprisedb.com ) On 1/15/07, Josef Springer <[EMAIL PROTECTED] > wrote: Hi folks, i have a workgroup (not a classic server) with Windows-XP-machines: the database server machine contains the line host all all 0.0.0.0 0.0.0.0 md5 in the file pg_hba.conf and listen_addresses = '*' in the file postgresql.conf. The clients' host file contain the line nnn.nnn.nnn.nnn Labor where nnn.nnn.nnn. is the IP-adress of the database server machine and /Labor /is the machine's name. If i start PGAdmin III on the 'client' machine i can not connect to the database on the machine Labor no matter wether i use the machine's name or the IP-adress. Instead i get the message "Zum Server ist keine Verbindung möglich, oder Login/Passwort sind falsch. Die Anmeldung wurde abgelehnt." Please help me. What to do ? mit freundlichen Grüßen / best regards, Josef Springer (Geschäftsleitung/Management) Address [EMAIL PROTECTED] Orlando-di-Lasso Str. 2 D-85640 Putzbrunn Office +49 (0)89 600 6920 Fax +49 (0)89 600 69220 Web http://www.joops.com -- the software company --
Re: [ADMIN] Can not connect to database in Workgroup-Net on Windows-XP
The error you are getting is because of the password not been passed correctly so 'trust' will let you get in the server without specifying the correct password, once you are in now you can change the password as you like using ALTER USER command. Once its done change it back to md5 as it was before. -- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/15/07, Josef Springer <[EMAIL PROTECTED]> wrote: Hi Mir, thanks for your quick answer. We will try this. For my unterstanding: Why should i use *trust *instead of *md5 * ? A configuration at another customer (with a *domain *setting) using *md5 *works fine ? mit freundlichen Grüßen / best regards, Josef Springer (Geschäftsleitung/Management) [image: Postal] Address [EMAIL PROTECTED] Orlando-di-Lasso Str. 2 D-85640 Putzbrunn [image: Phone] Office +49 (0)89 600 6920 [image: Phone] Fax +49 (0)89 600 69220 [image: Web] Web http://www.joops.com [image: JOOPS] *-- the software company --* Shoaib Mir wrote: I can understand the exact error as its not in english :) but it seems like an authentication problem. Please change 'md5' to 'trust' in pg_hba.conf file and then use: pg_ctl -D reload That will reload the settings for authentication. Now once the settings are reloaded try reconnecting to the database and it should go fine this time Shoaib Mir EnterpriseDB ( www.enterprisedb.com ) On 1/15/07, Josef Springer <[EMAIL PROTECTED] > wrote: > > Hi folks, > > i have a workgroup (not a classic server) with Windows-XP-machines: > > the database server machine contains the line > *host allall 0.0.0.0 0.0.0.0 md5* > in the file pg_hba.conf > and > *listen_addresses = '*' * > in the file postgresql.conf. > > The clients' host file contain the line > *nnn.nnn.nnn.nnn Labor* where nnn.nnn.nnn. is the IP-adress of > the database server machine and /Labor /is the machine's name. > > If i start PGAdmin III on the 'client' machine i can not connect to > the database on the machine Labor no matter wether i use the machine's > name > or the IP-adress. Instead i get the message > > * "Zum Server ist keine Verbindung möglich, * > > * oder Login/Passwort sind falsch.* > > * Die Anmeldung wurde abgelehnt."* > > > Please help me. What to do ? > > mit freundlichen Grüßen / best regards, > Josef Springer > (Geschäftsleitung/Management) > > [image: Postal] > Address > * [EMAIL PROTECTED] * > Orlando-di-Lasso Str. 2 > D-85640 Putzbrunn > [image: Phone] > Office > +49 (0)89 600 6920 > > > [image: Phone] > Fax > +49 (0)89 600 69220 > > > [image: Web] > Web > http://www.joops.com > > > > [image: JOOPS] > *-- the software company --* > > > > >
[ADMIN] Pg_dump behaviour
I often perform single-table backups using pgadmin. Recently, a problem occurred while doing that kind of backup using pgadmin 1.6.2 and PostgreSQL 8.2.1 on a Windows server: When trying to backup a table contained in a specific schema, pg_dump can't find the table. For instance, I have a database named 'mdg', containing a schema named 'art', in turn containing a table named 'tefh'. When I try to backup this table to the root directory with pgadmin, it generates and executes the following command: pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -v -f "c:\tefh" -t tefh -n art mdg Pg_dump then raises the following error: pg_dump: No matching tables were found I tried some alternatives from the command line, but pg_dump only seems to make the single-table backup when the table name is qualified, as in: pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -v -f "c:\tefh" -t art.tefh mdg At this point, I'd say that the command generated by pgadmin should work, as it seems to be consistent with pg_dump documentation. Any hints ? Thank you. Hélder M. Vieira ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Database Create Date
Hi Jim, Thanks for your reply. Well..there is no particular reason for knowing the database create date, but I feel this information is something which should be known, especially in a development environment where multiple database are created and deleted. This helps in keep historical information. Regards -Original Message- From: Jim C. Nasby [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 11:01 PM To: Negandhi, Nishith Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] Database Create Date On Tue, Jan 09, 2007 at 09:22:49AM -0600, Negandhi, Nishith wrote: > Hi, > I need to know the create date of databases on PosegreSQL. > PG_DATABASE does not provide this information. > Are there any other system catalogs that can provide the above > information?? This is the second time I remember someone asking for this, so maybe it's worth adding... why is it you need to know when the database was created? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Pg_dump behaviour
"=?iso-8859-1?Q?H=E9lder_M._Vieira?=" <[EMAIL PROTECTED]> writes: > I often perform single-table backups using pgadmin. > Recently, a problem occurred while doing that kind of backup using pgadmin > 1.6.2 and PostgreSQL 8.2.1 on a Windows server: > For instance, I have a database named 'mdg', containing a schema named > 'art', in turn containing a table named 'tefh'. > When I try to backup this table to the root directory with pgadmin, it > generates and executes the following command: > pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -v -f "c:\tefh" -t > tefh -n art mdg That was the pre-8.2 way to do it; now the right thing would be -t art.tefh Sounds like pgadmin needs an update. While they're at it, they should definitely lose the -i switch ... using that by default is extremely stupid/dangerous. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[ADMIN] PostgreSQL data dir on linux raid software
Hi, after some test i got that my performance problem described in the message http://archives.postgresql.org/pgsql-admin/2007-01/msg00116.php is issued by the linux software raid 1 on my discs (yes the silicon image controller has only fake raid hardware). I found this old message that seems the same problem like mine. http://archives.postgresql.org/pgsql-admin/2003-12/msg00219.php Because the message is quite old I'm wondering if there're some hdparm settings to enable on the disks that compose the array to have better performances in fsync. For now I cannot mount an expensive scsi raid hardware so i need to have raid software. Thanks in advance Best Regards Federico Campoli ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[ADMIN] PL/pgSQL Return statements
Hello, I am currently trying to upgrade PostgreSQL from 8.0 to 8.1 on our development machine and have run into a problem with RETURN VOID; statements in PL/pgSQL functions that have a return type of void. I'm getting errors like the following: ERROR: RETURN cannot have a parameter in function returning void at or near "VOID" at character 2983. Does this mean I must edit every function that is declared with RETURNS VOID and remove the RETURN VOID; statement from the body? I did a pg_dumpall using the 8.1 libraries on the 8.0 database and this made no difference. Thanks in advance, regards Donald Fraser
Re: [ADMIN] Invalid Checksum in Control File
>> "Christopher Bland" <[EMAIL PROTECTED]> writes: >> FATAL: incorrect checksum in control file > >Does pg_controldata print anything useful? > > regards, tom lane I *just* re-initialized the database and started over. I didn't think I had a dump of the original but then I found it. Thanks for replying. Chris FREE Reminder Service - NEW from AmericanGreetings.com Click HERE and never forget a Birthday or Anniversary again! http://track.juno.com/s/lc?s=197335&u=http://www.americangreetings.com/products/online_calendar.pd?c=uol5752 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] PL/pgSQL Return statements
"Donald Fraser" <[EMAIL PROTECTED]> writes: > I'm getting errors like the following: > ERROR: RETURN cannot have a parameter in function returning void at or = > near "VOID" at character 2983. > Does this mean I must edit every function that is declared with RETURNS = > VOID and remove the RETURN VOID; statement from the body? Yup. That was never correct code, but plpgsql used to completely ignore anything after RETURN in a function declared to return VOID. Which surprised enough people that we changed it ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [ADMIN] Pg_dump behaviour
- Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Hélder M. Vieira" <[EMAIL PROTECTED]> Cc: Sent: Monday, January 15, 2007 3:39 PM Subject: Re: [ADMIN] Pg_dump behaviour ... That was the pre-8.2 way to do it; now the right thing would be -t art.tefh Sounds like pgadmin needs an update. ... Thanks for clarifying. The second note in the '-t' option description in the pg_dump documentation is a clear warning. I'll submit a bug report in the pgadmin mailling list. Regards, Helder M. Vieira ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
