Hello all,
currently we have a server down problem. The server is a IBM xSeries
306, 1GB RAM, HD 36GB RAID1. Operating System ist Debian Sarge 3.1.
Postgresql version is 7.4.7.
The reason for this ist not knwon. The postmaster won't come up any
more. Here is the relevant content of the
I am in the process of converting an old system to a
new system where I have chosen to use postgres in
stead of a home grow system based on b-trees.
The system receives 2650 message a total of 10Mbytes
of data per 15 minutes this information have to be
store in 4 tables in the database. Some of
Volker [EMAIL PROTECTED] writes:
currently we have a server down problem. The server is a IBM xSeries
306, 1GB RAM, HD 36GB RAID1. Operating System ist Debian Sarge 3.1.
Postgresql version is 7.4.7.
The reason for this ist not knwon. The postmaster won't come up any
more. Here is the relevant
It takes 6 minutes to ingest the data with an empty
database and 25 minutes (wall time) if all the data is
already in the database.
The processing is done as follows:
1. Start transaction
2. check if message is in table 1 and if so delete
records from table 1(1 row),2(2 rows),3(30 rows),4(50
andre wrote:
1) Which sql queries should I use to detect deadlocks while they are
happening? I see the deadlock info on the log file, but I'd like to
query the database to see them as they happen...
Since deadlocks are broken up within one second, it will be hard to
actually see them. You
When I update pg_hba.conf to disallow certain client
machines from connectiong (update pg_hba.conf, pg_ctl reload), I still see new
connections appearing in the process list from the clients I want to
disconnect. Why does this happen. (I noticed this behavior with jdbc
connections in jboss
Sriram Dandapani [EMAIL PROTECTED] writes:
When I update pg_hba.conf to disallow certain client machines from
connectiong (update pg_hba.conf, pg_ctl reload), I still see new
connections appearing in the process list from the clients I want to
disconnect.
Sounds to me like a mistake in your
This is the complete pg_hba contents
local all all trust
# IPv4 local connections:
hostall all 127.0.0.1/32 trust
#host all all 172.31.0.84/24trust
# IPv6 local connections:
hostall all
Sriram Dandapani [EMAIL PROTECTED] writes:
This is the complete pg_hba contents
local all all trust
# IPv4 local connections:
hostall all 127.0.0.1/32 trust
#host all all 172.31.0.84/24trust
# IPv6
Tom Lane wrote:
Sriram Dandapani [EMAIL PROTECTED] writes:
When I update pg_hba.conf to disallow certain client machines from
connectiong (update pg_hba.conf, pg_ctl reload), I still see new
connections appearing in the process list from the clients I want to
disconnect.
Sounds to me like a
This problem occurs only when the changes are made while postmaster is
running and pg_ctl is used to reload config files.
When the changes are applied and postmaster is stopped and restarted, it
works fine.
-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent:
Sriram Dandapani [EMAIL PROTECTED] writes:
This problem occurs only when the changes are made while postmaster is
running and pg_ctl is used to reload config files.
When the changes are applied and postmaster is stopped and restarted, it
works fine.
Hm. OK, that means we need to look closer
Pg_ctl is pointing to the same directory that postmaster points to on
startup. There is only 1 data directory/postgres installation that I
use.
Pg_ctl informs that postmaster is signaled. When I see the logs for
postmaster, it says received SIGHUP, reloading configuration files
Linux
Sriram Dandapani [EMAIL PROTECTED] writes:
Pg_ctl is pointing to the same directory that postmaster points to on
startup. There is only 1 data directory/postgres installation that I
use.
Pg_ctl informs that postmaster is signaled. When I see the logs for
postmaster, it says received SIGHUP,
On Wed, 2006-08-23 at 14:45, andre wrote:
Hi,
We are using Postgres 7.4.5, and I'm trying to find a way to detect
and gather deadlock information.
1) Which sql queries should I use to detect deadlocks while they are
happening? I see the deadlock info on the log file, but I'd like to
Changing limit or offset to a small number doesn't have any change in
plans. Likewise enable_seqscan to false. They still take 8-10 mins to
runs.
-Original Message-
From: Dave Dutcher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 4:20 PM
To: Subbiah, Stalin
Cc:
16 matches
Mail list logo