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
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
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
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
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
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
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
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
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 (
[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
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
"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
"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.
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
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
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.
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
> 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_
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
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
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
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
22 matches
Mail list logo