On Mon, 2009-08-03 at 16:02 -0500, Plugge, Joe R. wrote:
> What version of Slony-I is "ok" to use with version 8.4.0, I am
> getting this error when trying to make against 8.4.0 on RHEL4:
I just tested building 1.2.17rc on RHEL4 -- it worked fine.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://ww
On Mon, Aug 3, 2009 at 4:02 PM, Rodrigo E. De León
Plicet wrote:
> On Mon, Aug 3, 2009 at 11:15 AM, Brian Modra wrote:
>> (...) and 6x300GB SAS RAID 10 for the database... but some experts have said
>> RAID 5 is fine. I'm inlined to think RAID 10, but I'm not an expert.
>
> These guys:
>
> http://w
Andrew Perrin wrote:
> 1.) Is there a way to "reconnect" the 8.3 server, after reinstalling
> it, to the raw files, so that the databases are there? I will then
> do a pg_upgradecluster and be happy; or, alternatively,
If you're in a hurry, just install 8.3 from source and run postmaster -D
/path
On Mon, Aug 3, 2009 at 11:15 AM, Brian Modra wrote:
> (...) and 6x300GB SAS RAID 10 for the database... but some experts have said
> RAID 5 is fine. I'm inlined to think RAID 10, but I'm not an expert.
These guys:
http://www.baarf.com/
... kinda dislike RAID5 with a passion; dunno if it's relate
On Mon, Aug 3, 2009 at 10:15 AM, Brian Modra wrote:
> Hi,
> my database is hit with constant inserts to 6 main tables (200 inserts
> per minute to one of the tables, less to the others), some updates,
> but then the selects:
> - large retrievals of randomly different sections of the database
> (ind
Greetings all-
Running postgresql under debian, my standard apt-get upgrade upgraded me
from 8.3 to 8.4. As a result, I no longer have access to the databases
that were created under 8.3. Typically I would use pg_upgradecluster to
fix this problem; however, the upgrade also removed 8.3, and so
Hi,
my database is hit with constant inserts to 6 main tables (200 inserts
per minute to one of the tables, less to the others), some updates,
but then the selects:
- large retrievals of randomly different sections of the database
(indexed maps by postgis). This data is static.
- medium sized retri
slony1-1.2.17-rc ...
Thank you
-Original Message-
From: Kenneth Marshall [mailto:k...@rice.edu]
Sent: Monday, August 03, 2009 4:27 PM
To: Plugge, Joe R.
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Slony-I Version with Postgres 8.4.0
You need to latest release candidate that
You need to latest release candidate that was announced last week.
The expected actual release is to be this week. I am waiting for
that.
Regards,
Ken
On Mon, Aug 03, 2009 at 04:02:16PM -0500, Plugge, Joe R. wrote:
> What version of Slony-I is "ok" to use with version 8.4.0, I am getting this
>
What version of Slony-I is "ok" to use with version 8.4.0, I am getting this
error when trying to make against 8.4.0 on RHEL4:
[postg...@linux1558 slony1-1.2.15]$ make
make[1]: Entering directory `/home/postgres/slony1-1.2.15/src'
make[2]: Entering directory `/home/postgres/slony1-1.2.15/src/xxid
Ian Lea wrote:
> The advantage of setting it high is that you'll use less disk space
> and have fewer files to archive.
Although you can mitigate the space problem by using pg_clearxlogtail
(combined with gzip) or pglesslog from pgfoundry.
-Kevin
--
Sent via pgsql-admin mailing list (pgsq
Hello Tom and others who replied.
I appreciate the help tracking this down and eventually determining there is
no point tracking it down further.
We will do our best recovering what is accessible from the corrupt DB and an
older backup.
Thanks,
Michael.
On Fri, Jul 31, 2009 at 7:18 PM, Tom Lane
On Thu, Jul 30, 2009 at 5:04 AM, James Haworth wrote:
> Hi,
>
> I am using postgresql 8.3 with postgis 1.3.6 to do a masters project. I
> have been running the database without any problems for a few months now
> and all of a sudden I cannot connect to it. I get the error:
>
> "could not connect to
"Mark Steben" writes:
> Is it possible that, during startup, postmaster.pid takes a second or two to
> be created and hadn't been created yet when the test was run?
It's not instantaneous, for sure. For one thing, the kernel could be
scheduling the postmaster at lower priority than the continue
Hi folks, were running Postgres 8.2.5 and Linux Redhat.
I run a cron script to start our server using pg_ctl after I copy the data
cluster over from a replicated server.
To test the start success / failure I test for the presence of
postmaster.pid in the cluster.
This weekend, the server started s
Venkateswara Rao Bondada wrote:
Hi,
I'm new to PostgreSQL, and currently facing an issue with PostgreSQL
7.4 database. I'm getting the following error when tried to create a
table. Please let me know the steps (with queries) that I should take
care to resolve this issue.
cms=# create
Thank you Ian. I'm clear now.
--
View this message in context:
http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24790968.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to
> 1) What is the advantage / disadvantage of setting "archive_timeout" command
> to too small or too high value?
The advantage of setting it high is that you'll use less disk space
and have fewer files to archive.
The disadvantage of setting it high is that you might lose more data.
In your 30 m
Hi,
I'm new to PostgreSQL, and currently facing an issue with PostgreSQL 7.4
database. I'm getting the following error when tried to create a table. Please
let me know the steps (with queries) that I should take care to resolve this
issue.
cms=# create table test(id character varying(80));
ERRO
Essentially, my question here is
1) What is the advantage / disadvantage of setting "archive_timeout" command
to too small or too high value?
2) What is the impact of setting this value during PITR recovery process?
--
View this message in context:
http://www.nabble.com/PITR-archive_timeout-Co
Hi Ian,
Ian Lea wrote:
>
> "We could stop the replay at any point and have a
> consistent snapshot of the database as it was at that time. Thus, this
> technique supports point-in-time recovery: it is possible to restore
> the database to its state at any time since your base backup was
> taken
1) Exactly the database was at 10:15 am
From http://www.postgresql.org/docs/8.3/static/continuous-archiving.html
"There is nothing that says we have to replay the WAL entries all the
way to the end. We could stop the replay at any point and have a
consistent snapshot of the database as it was at
Hi,
I have a basic and quick question related to "archive_timeout" command in
PITR.
I've set "archive_timeout" to 1800 seconds (30 minutes) in
"postgresql.conf", which means WAL archives are generated every 30 minutes.
So, if for an example my WAL archives are generated at the following time:
23 matches
Mail list logo
