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 ple
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 inve
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 the
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 t
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 over
On Mon, Sep 29, 2008 at 2:16 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "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 pr
"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 data
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 argu
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.
Yo
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] writ
[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 kil
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 o
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 yo
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, correct
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
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 t
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 droppi
"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 syste
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 chan
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 be
I can't resist one-liner games.
$ perl -e 'print "U"x(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
