Re: [ADMIN] PostgreSQL 8.4 x Win 2008 - slow connection

2010-08-25 Thread Fábio Gibon - Comex System
Thanks a lot... i will check this too. Fábio Gibon - Original Message - From: "Scott Marlowe" To: "Fábio Gibon - Comex System" Cc: "PostgreSQL - mailing list" Sent: Wednesday, August 25, 2010 6:47 PM Subject: Re: [ADMIN] PostgreSQL 8.4 x Win 2008 - slow connection On Tue, Aug 24, 2

Re: [ADMIN] PostgreSQL 8.4 x Win 2008 - slow connection

2010-08-25 Thread Scott Marlowe
On Tue, Aug 24, 2010 at 8:05 PM, Fábio Gibon - Comex System wrote: > I'm having problems with connection time using Post 8.4 on Win 2008 > enterprise (32bits). To do open/close 10 connections i lost about 20 seconds > and doing the same test using Post 8.4 in another server (Win 2003) on 20 > seco

Re: [ADMIN] PostgreSQL 8.4 x Win 2008 - slow connection

2010-08-25 Thread Scott Marlowe
On Tue, Aug 24, 2010 at 8:05 PM, Fábio Gibon - Comex System wrote: > I'm having problems with connection time using Post 8.4 on Win 2008 > enterprise (32bits). To do open/close 10 connections i lost about 20 seconds > and doing the same test using Post 8.4 in another server (Win 2003) on 20 > seco

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Kevin Grittner
Dragos Valentin Moinescu wrote: > I did not use rsyncd. I used "rsync -avz u...@host:/pgsqldata > /localpgdata". Will read about rsyncd You don't need to run the rsyncd service to get a daemon -- we use the remote shell technique, through ssh. If you're using the :: syntax (versus :/), you ar

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Joshua D. Drake
On Wed, 2010-08-25 at 22:39 +0300, Dragos Valentin Moinescu wrote: > What I did in terms of warm standby: > 1. base backup using rsync > 2. rsync all wal files > 3. edited recoverfy.conf with a recovery_command="cp /wal-archive/%f %p" > > So I need to write a new recovery_command that actually pr

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Dragos Valentin Moinescu
On Wed, Aug 25, 2010 at 6:11 PM, Kevin Grittner wrote: > [Rearranged somewhat.  Please don't top-post, but put responses at > the appropriate point in-line.  I've had to guess a bit at what was > responding to what; apologies for any misinterpretation.] Sorry about that:) > > Dragos Valentin Moi

Re: [ADMIN] loading a lot of data on windows is very slow

2010-08-25 Thread Tom Lane
Kasia Tuszynska writes: > PG: 8.3.8 > 2010-08-18 20:29:42 PDT ERROR: out of memory > 2010-08-18 20:29:42 PDT DETAIL: Failed on request of size 134217728. What command is this failure occurring in? There aren't that many that would try to inhale your full work_mem in one gulp like that. The sh

[ADMIN] loading a lot of data on windows is very slow

2010-08-25 Thread Kasia Tuszynska
Hi Everybody, Sorry for the vague post but I am looking for ideas in diagnosing a problem. I am wondering if I am missing something obvious for Postgres or maybe I failed to check something. Does anyone have any suggestions? Sincerely, Kasia OS: windows 2008, 32bit dual processor, 4 gigs of RAM

Re: [ADMIN] PostgreSQL 8.4 x Win 2008 - slow connection

2010-08-25 Thread Scott Marlowe
Please keep the list cc'd to your replies On Wed, Aug 25, 2010 at 6:22 AM, Fábio Gibon - Comex System wrote: > Tks Scott... >        but I did tests connecting by network and local, both was very > slowly. That in no way proves it's not a network problem. -- Sent via pgsql-admin mailing list (

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Kevin Grittner
[Rearranged somewhat. Please don't top-post, but put responses at the appropriate point in-line. I've had to guess a bit at what was responding to what; apologies for any misinterpretation.] Dragos Valentin Moinescu wrote: > Kevin Grittner wrote: > I used rsync to create a base backup. Thou

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Dragos Valentin Moinescu
I used rsync to create a base backup. Though I have 10 huge tables (min 1GB each) that are modified several times a second, thus creating a base backup hourly means I have to sync arround 10G each time (which is pretty time consuming). I do not want to use the standby server. This is why I am pret

Re: [ADMIN] last_autovacuum & last_autoanalyze showing NULL

2010-08-25 Thread Tom Lane
"Gnanakumar" writes: >> Has your Postgres instance crashed or been restarted with immediate mode >> since the last vacuum? This will cause the autovacuum information to be >> null. > No, it's been up and running for almost a week. I even checked with "select > pg_postmaster_start_time()". I do

Re: [ADMIN] Autovacuum daemon & TEMPORARY tables

2010-08-25 Thread Tom Lane
"Gnanakumar" writes: > Does autovacuum daemon work on tables created with TEMPORARY syntax? No. It can't, because it's unsafe for any session except the creating session to touch a temporary table. The performance optimizations used for temp tables have that unfortunate side-effect.

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Kevin Grittner
Dragos Valentin Moinescu wrote: > Where can I find information about how to modify the postgresql > server in order to allow this in 8.2.17? You haven't exactly said what "this" is, but I am inferring that you want to bring your standby up to run read-only queries once per hour, and then resum

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Dragos Valentin Moinescu
Thanx for your reply. Still, we are talking about 80G databases which are heavily used. I cannot wait for 9.0 (which is still in beta). I really need a solution ASAP. Where can I find information about how to modify the postgresql server in order to allow this in 8.2.17? Thank you On Wed, Aug

Re: [ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Kevin Grittner
Dragos Valentin Moinescu wrote: > 8.2.3 production server http://www.postgresql.org/support/versioning http://www.postgresql.org/docs/8.2/static/release.html > backup server ... that should keep updating hourly the db cluster > based on WAL files received from production server http://www.

[ADMIN] 8.2 "real-time" recovery

2010-08-25 Thread Dragos Valentin Moinescu
Hello, I have this scenario: 1. 8.2.3 production server (32 bit) with WAL archive active 2. 8.2.17 backup server (32bit running on 64bit) that should keep updating hourly the db cluster based on WAL files received from production server The problem is that after the first recovery the backup serv

Re: [ADMIN] last_autovacuum & last_autoanalyze showing NULL

2010-08-25 Thread Gnanakumar
> Truncate should not affect those values. OK. > Has your Postgres instance crashed or been restarted with immediate mode since the last vacuum? This will cause the autovacuum information to be null. No, it's been up and running for almost a week. I even checked with "select pg_postmaster_start_

Re: [ADMIN] last_autovacuum & last_autoanalyze showing NULL

2010-08-25 Thread Brad Nicholson
On 10-08-25 03:30 AM, Gnanakumar wrote: Hi, Our production server is running PostgreSQL v8.2.3 on RHEL5. Autovacuum daemon is also running in the server. A brief background on my use case: We heavily use a table for storing of data temporarily inside PostgreSQL functions. Eventually, there

[ADMIN] Autovacuum daemon & TEMPORARY tables

2010-08-25 Thread Gnanakumar
Hi, Does autovacuum daemon work on tables created with TEMPORARY syntax? CREATE [ { TEMPORARY | TEMP } ] TABLE table_name ... Regards, Gnanam -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin

Re: [ADMIN] SQL statements not printed in pgpool log

2010-08-25 Thread Gnanakumar
Solution is here: http://pgfoundry.org/pipermail/pgpool-general/2010-August/002910.html -Original Message- From: Gnanakumar [mailto:gna...@zoniac.com] Sent: Tuesday, August 17, 2010 7:38 PM To: pgsql-admin@postgresql.org Subject: RE: SQL statements not printed in pgpool log Any ideas/sug

[ADMIN] last_autovacuum & last_autoanalyze showing NULL

2010-08-25 Thread Gnanakumar
Hi, Our production server is running PostgreSQL v8.2.3 on RHEL5. Autovacuum daemon is also running in the server. A brief background on my use case: We heavily use a table for storing of data temporarily inside PostgreSQL functions. Eventually, there will not be any record in the table. Becau