-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
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 i
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
> >
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 loa
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 loa
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 colum
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.postgres
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 data
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
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
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 in
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 INSERT
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 :
Peter Bauer wrote:
> - Two of these clusters are using the same PostgreSQL installation to
> share the data
Just checking - you're not
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
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 table
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 transact
its ("b").
Alexander.
On Oct 5, 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?
>
> t
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
e amount 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
> loadte
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 perform
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 att
2006/10/1, Matthew T. O'Connor :
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 in just
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
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% i
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 a
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 st
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 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 br
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
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 RAI
31 matches
Mail list logo
