On Mon, 29 Sep 2008, Matthew Pulis wrote:
I need to perform some timed testing, thus need to make sure that disk cache
does not affect me. Is clearing the OS (Ubuntu) disk cache, ( by running:
sudo echo 3 | sudo tee /proc/sys/vm/drop_caches ) enough to do this?
What you should do is:
1)
Matthew Pulis wrote:
Hi,
I need to perform some timed testing, thus need to make sure that disk
cache does not affect me. Is clearing the OS (Ubuntu) disk cache, ( by
running: sudo echo 3 | sudo tee /proc/sys/vm/drop_caches ) enough to
do this? If not can you please point me to some site
A while ago I wrote a script based on Dave Plonka work
http://net.doit.wisc.edu/~plonka/fincore/
My script monitors system buffers and shared buffers
(if pg_buffercache installed) and I found it's almost useless to
check system buffers, since I got rather ridiculous numbers.
I use it to
Hi,
We have a number of automated performance tests (to test our own code)
involving PostgreSQL. Test cases are supposed to drop and recreate
tables each time they run.
The problem is that some of the tests show a linear performance
degradation overtime. (We have data for three months back in
PS:
PGSQL version is: 8.2.7. (BTW, which catalog view contains the
back-end version number?)
On Mon, Sep 29, 2008 at 11:37 AM, Peter Kovacs
[EMAIL PROTECTED] wrote:
Hi,
We have a number of automated performance tests (to test our own code)
involving PostgreSQL. Test cases are supposed to
Hi,
I have installes Postgres 8.0.15 on a embedded Linux and have only 130
MB for Postgres.
Is it possible to turn off the comlete (Wal) pg_xlog? Because this is
the biggest part.
I found an Entry how to minimize the count of stored xlogs.
Is it possible to store it to /dev/null or something
Peter Kovacs [EMAIL PROTECTED] writes:
We have a number of automated performance tests (to test our own code)
involving PostgreSQL. Test cases are supposed to drop and recreate
tables each time they run.
The problem is that some of the tests show a linear performance
degradation overtime.
Peter Kovacs [EMAIL PROTECTED] writes:
It is not immediately clear from the documentation, but the VACUUM
command also deals with the system catalogs as well, correct?
If it's run without any argument by a superuser, then yes.
(I think in recent versions we also allow a non-superuser database
Thank you!
Peter
On Mon, Sep 29, 2008 at 2:42 PM, Tom Lane [EMAIL PROTECTED] wrote:
Peter Kovacs [EMAIL PROTECTED] writes:
It is not immediately clear from the documentation, but the VACUUM
command also deals with the system catalogs as well, correct?
If it's run without any argument by a
I am hoping someone can help a novice understand the process of ID
wraparound, I have read many of the articles
on the web but don't understand why my age(datfrozenxid) never gets reset.
I am not sure if I even have a
problem, just trying to be proactive.
First the details:
select version()
[EMAIL PROTECTED] writes:
I am hoping someone can help a novice understand the process of ID
wraparound, I have read many of the articles
on the web but don't understand why my age(datfrozenxid) never gets reset.
I am not sure if I even have a
problem, just trying to be proactive.
You
Thank you Tom..
Can you recommend any documentation that explains the process?
Keith Kreuzer
ext 3424
Tom Lane [EMAIL PROTECTED]
09/29/2008 10:00 AM
To
[EMAIL PROTECTED]
cc
pgsql-admin@postgresql.org
Subject
Re: [ADMIN] understand the process of ID wraparound
[EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Can you recommend any documentation that explains the process?
Did you read
http://www.postgresql.org/docs/8.3/static/routine-vacuuming.html
(adjust URL if you are running some other major PG version)
regards, tom lane
--
Sent via pgsql-admin
On Mon, Sep 22, 2008 at 4:43 PM, Tom Lane [EMAIL PROTECTED] wrote:
Vladimir Rusinov [EMAIL PROTECTED] writes:
But now I'm getting following error:
pg_dump: WARNING: terminating connection because of crash of another server
process
As a rule of thumb, you should disable OOM kill on any
On Sun, Sep 28, 2008 at 2:18 AM, Peter Kovacs
[EMAIL PROTECTED] wrote:
On Mon, Sep 22, 2008 at 4:43 PM, Tom Lane [EMAIL PROTECTED] wrote:
Vladimir Rusinov [EMAIL PROTECTED] writes:
But now I'm getting following error:
pg_dump: WARNING: terminating connection because of crash of another server
On Mon, Sep 29, 2008 at 01:00:41PM +0200, Jonny wrote:
Is it possible to turn off the comlete (Wal) pg_xlog?
No.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to
What it sounds like to me is that you're not vacuuming the system
catalogs, which are getting bloated with dead rows about all those
dropped tables.
Wow, great!
It is not immediately clear from the documentation, but the VACUUM
command also deals with the system catalogs as well,
On Mon, Sep 29, 2008 at 11:12 AM, Steve Crawford
[EMAIL PROTECTED] wrote:
What it sounds like to me is that you're not vacuuming the system
catalogs, which are getting bloated with dead rows about all those
dropped tables.
Wow, great!
It is not immediately clear from the documentation,
Hello,
We are operating Postgresql 8.2 on an ISCSI environment. Sometimes there are
issues with the ISCSI so Postgresql refuses to shutdown properly, or start,
because of the pid file. My question is, what is the correct thing to do
with this pid file? On some test-environments I have deleted
On Mon, Sep 29, 2008 at 12:43:54PM -0500, Ing. Jorge S Alanís Garza wrote:
shutting down cleanly. Is there a way to recover the non-working postgres
instance? Is this a very corruption-prone environment?
It's sure corruption-prone if you delete the pidfile.
If your iSCSI system keeps
Scott Marlowe [EMAIL PROTECTED] writes:
Also, there was a time when you couldn't do vacuum full on system
tables do to locking issues, and had to take the db down to single
user mode to do so.
There was a short period when *concurrent* vacuum fulls on just the
wrong combinations of system
Tom Lane wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
Also, there was a time when you couldn't do vacuum full on system
tables do to locking issues, and had to take the db down to single
user mode to do so.
There was a short period when *concurrent* vacuum fulls on just the
wrong
Steve Crawford [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] CLUSTER pg_class USING pg_class_oid_index ;
ERROR: pg_class is a system catalog
I think the DB is probably protecting you from yourself here ;-).
If memory serves there are some system indexes whose relfilenode
numbers can't change,
Tom Lane wrote:
Steve Crawford [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] CLUSTER pg_class USING pg_class_oid_index ;
ERROR: pg_class is a system catalog
I think the DB is probably protecting you from yourself here ;-).
And elsewhere. :)
I wasn't advocating for a change of
I can't resist one-liner games.
$ perl -e 'print Ux(256*1024)' Us
or, if you specifically want to specify hex:
$ perl -e 'print chr(hex(55))x(256*1024)' Us
-Reece
--
Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0
25 matches
Mail list logo
