-string.html with the
various Built-in Conversions and
chr(int) which is only available for the ASCII charset.
thx,
Peter
--
Peter Bauer
APUS Software G.m.b.H.
A-8074 Raaba, Bahnhofstrasse 1/1
Email: [EMAIL PROTECTED]
Tel: +43 316 401629 24
Fax: +43 316 401629 9
---(end
is initialized again.
Is there a possibility to let the views live there even if the refered schema
or tables are dropped? Would a plpgsql Function also be dropped?
thx,
Peter
--
Peter Bauer
APUS Software G.m.b.H.
A-8074 Raaba, Bahnhofstrasse 1/1
Email: [EMAIL PROTECTED]
Tel: +43 316 401629 24
Fax
Hi Greg,
Am Mittwoch 28 November 2007 schrieb Greg Smith:
On Sat, 24 Nov 2007, Peter Bauer wrote:
top shows that the CPUs are at least 80% idle most of the time so i
think there is an I/O bottleneck.
top also shows that you're never waiting for I/O which is usually evidence
there isn't
Hi all,
i have a system here with 2 2.4GHz Xeon Processors, 2GB RAM, ONE Disk on
a Battery Backed Write Cache SCSI Controller and PostgreSQL 8.1.4
running with the data on a DRBD Device for High Availability. The used
database is also replicated to two similar machines with slony1.
Since the
Am Dienstag 27 November 2007 schrieb Scott Marlowe:
On Nov 24, 2007 10:57 AM, Peter Bauer [EMAIL PROTECTED] wrote:
i have a system here with 2 2.4GHz Xeon Processors, 2GB RAM, ONE Disk on
a Battery Backed Write Cache SCSI Controller and PostgreSQL 8.1.4
running with the data on a DRBD
Hi all,
i have a system here with 2 2.4GHz Xeon Processors, 2GB RAM, ONE Disk on
a Battery Backed Write Cache SCSI Controller and PostgreSQL 8.1.4
running with the data on a DRBD Device for High Availability. The used
database is also replicated to two similar machines with slony1.
Since the
Hi all,
i have a Debian Server here which is using an NTP server for time
synchronization. At the DST shifts, the server time is correctly set.
In the database on the server i have a table with a column which
contains timestamps but the type of the column is char(30). The
timestamps in this
Hi,
we had these problems with Version 7.4.7, you can find the old thread here:
http://archives.postgresql.org/pgsql-general/2006-09/msg00079.php
br,
Peter
2006/10/21, Chris Mair [EMAIL PROTECTED]:
its just a vacuumdb --all. We already learned that full vacuums are
evil because the
which lead to a unrecoverable situation because there
was constant load.
Is this a reasonable assumption or impossible nonsense?
thx,
Peter
2006/10/21, Peter Bauer [EMAIL PROTECTED]:
Hi,
we had these problems with Version 7.4.7, you can find the old thread here:
http://archives.postgresql.org
Hi all,
for further investigation we seperated the sub-SELECT from the DELETE
statement and it looks like the SELECT is usually finished in some 100
milliseconds but after some minutes it suddenly takes some minutes.
Peter
2006/10/20, Peter Bauer [EMAIL PROTECTED]:
Hi all,
we have a theory
waits to get a lock for some rows
which are exclusively locked by the DELETE statement (got from its
sub-SELECT).
What do you think about this theory?
thx,
Peter
2006/10/19, Peter Bauer [EMAIL PROTECTED]:
thank you very much, we will test it
br,
Peter
2006/10/19, Jim C. Nasby [EMAIL PROTECTED
Hi all,
we are struggling for some time now with PostgreSQL 8.1.4 and the
situation is pretty critical so please help with whatever comes to
your mind.
We even did an upgrade from version 7.4.13, tried different vacuum
configurations and optimized the configuration.
There is a table called
Hi,
its just a vacuumdb --all. We already learned that full vacuums are
evil because the database was carrupted after some time.
Regards,
Peter
2006/10/19, Tomasz Ostrowski [EMAIL PROTECTED]:
On Thu, 19 Oct 2006, Peter Bauer wrote:
A vaccum of the whole database is performed every 10
Hi,
the drbd device can only be active and mounted on one machine, so the
other is just in standby.
Regards,
Peter
2006/10/19, Richard Huxton dev@archonet.com:
Peter Bauer wrote:
- Two of these clusters are using the same PostgreSQL installation to
share the data
Just checking - you're
thank you, so we will perform the tests with such a vacuum configuration,
br,
Peter
2006/10/19, Tom Lane [EMAIL PROTECTED]:
Peter Bauer [EMAIL PROTECTED] writes:
There is a table called tableregistrations where per day about
1 million rows are INSERTed
2 SELECTs should be performed
thank you very much, we will test it
br,
Peter
2006/10/19, Jim C. Nasby [EMAIL PROTECTED]:
On Thu, Oct 19, 2006 at 01:57:56PM +0200, Peter Bauer wrote:
In the update statement, don't wrap the ID values in quotes. At best
it's extra work; at worse it will fool the planner into not using
Hi all,
2006/10/5, Tom Lane [EMAIL PROTECTED]:
Peter Bauer [EMAIL PROTECTED] writes:
tps = 50.703609 (including connections establishing)
tps = 50.709265 (excluding connections establishing)
That's about what you ought to expect for a single transaction stream
running on honest disk hardware
Hi all,
inspired by the last posting Weird disk write load caused by
PostgreSQL? i increased the work_mem from 1 to 7MB and did some
loadtest with vacuum every 10 minutes. The system load (harddisk) went
down and everything was very stable at 80% idle for nearly 24 hours!
I am currently
of work memory that has spilled over into pgsql_tmp.
Alexander.
On Oct 5, 2006, at 10:48 , Peter Bauer wrote:
Hi all,
inspired by the last posting Weird disk write load caused by
PostgreSQL? i increased the work_mem from 1 to 7MB and did some
loadtest with vacuum every 10 minutes. The system
I forgot to mention that top does not show a noticeable increase of
CPU or system load during the pgbench runs (postmaster has 4-8% CPU).
Shouldn't the machine be busy during such a test?
thx,
Peter
2006/10/5, Peter Bauer [EMAIL PROTECTED]:
I finished the little benchmarking on our server
, 2006, at 14:35 , Peter Bauer wrote:
I forgot to mention that top does not show a noticeable increase of
CPU or system load during the pgbench runs (postmaster has 4-8% CPU).
Shouldn't the machine be busy during such a test?
thx,
Peter
2006/10/5, Peter Bauer [EMAIL PROTECTED]:
I finished
2006/10/2, Tom Lane [EMAIL PROTECTED]:
Peter Bauer [EMAIL PROTECTED] writes:
Attached you can find the postgresql logfiles and a logfile which
contains alls SQL statements executed in the relevant time together
with the excpetions thrown. I also attached a file with all used
Pl/pgSQL
Hi all,
i have a Tomcat application with PostgreSQL 8.1.4 running which
performs about 1 inserts/deletes every 2-4 minutes and updates on
a database and after some hours of loadtesting the top output says
0.0% idle, 6-7% system load, load average 32, 31, 28 and there are
many exceptions at
2006/10/1, Peter Bauer [EMAIL PROTECTED]:
Hi all,
i have a Tomcat application with PostgreSQL 8.1.4 running which
performs about 1 inserts/deletes every 2-4 minutes and updates on
a database and after some hours of loadtesting the top output says
0.0% idle, 6-7% system load, load average 32
2006/10/1, Chris Mair [EMAIL PROTECTED]:
Hi,
a few random question...
i have a Tomcat application with PostgreSQL 8.1.4 running which
performs about 1 inserts/deletes every 2-4 minutes and updates on
a database and after some hours of loadtesting the top output says
0.0% idle, 6-7%
2006/10/1, MaXX [EMAIL PROTECTED]:
Peter Bauer wrote:
2006/10/1, MaXX [EMAIL PROTECTED]:
Peter Bauer wrote:
[...]
There are 10-15 postmaster processes running which use all the CPU
power.
A restart of tomcat and then postgresql results in the same situation.
Some postgres processes
2006/10/1, Matthew T. O'Connor matthew@zeut.net:
MaXX wrote:
There are 10-15 postmaster processes running which use all the CPU
power.
A restart of tomcat and then postgresql results in the same situation.
Some postgres processes are in DELETE waiting or SELECT waiting.
VACUUM runs through
Has nobody an idea what could have happened?
thx,
Peter
-- Weitergeleitete Nachricht --
Subject: Multiple entries of same table in pg_class
Date: Dienstag, 12. September 2006 13:19
From: Peter Bauer [EMAIL PROTECTED]
To: pgsql-general@postgresql.org
Hi all,
after extensive
Hi all,
after extensive logfilechecking we found out that there are 70 entries
for the same table in pg_class which are identical.
Dropping the table results in a missing attribute ... error for this relation.
PostgreSQL 7.4.7
Debian Sarge
regards,
Peter
---(end of
First thanks to all for your immediate help!
2006/9/3, Tom Lane [EMAIL PROTECTED]:
Peter Bauer [EMAIL PROTECTED] writes:
- OS: Debian Sarge with postgresql-7.4.7-6sarge1
You do know that we're up to 7.4.13 in that branch? There were some
pretty serious bugs found in 7.4 since 7.4.7, so I
Hi all,
like always, time is short and we have a very critical situation here,
so please help to save the day once again.
Installation facts:
- 4 High Availability Clusters consisting of 2 Dual Xeon Server
machines (Dell PowerEdge 2850) using Heartbeat1. Each server has only
one harddisk, no
31 matches
Mail list logo
