[ADMIN] CESTLOG: statistics buffer is full

2007-04-23 Thread Achakzai, Omar
Hi, We use PostgreSQL version 8.1.4. Autovacuum is on. The message "CESTLOG: statistics buffer is full" appears repeatedly in the logfile of the database. I searched on the Internet, but couldn't find much about this message. What kind of statistics is being kept in the statistics buffer? Wh

Re: [ADMIN] pg_standby, Restartable Recovery after Hard Failure

2007-04-23 Thread Simon Riggs
On Wed, 2007-04-18 at 18:11 -0500, Thomas F. O'Connell wrote: > Wanting a nice test of restartable recovery and pg_standby in a warm > standby server scenario I'm testing, today I pulled the plug on the > box where I was using Simon's test_warm_standby test harness. > Basically, in this scenario, I

Re: [ADMIN] pg_dump and pg_restore with different owners

2007-04-23 Thread Jaume Sabater
Jaume Sabater wrote: Hello everyone! I am resending this email to see whether I have better luck now. I've been digging the Internet with no luck for the past few days. We have a two servers, "devel" and "live", both running PostgreSQL 8.1.8. At the devel server there is the database "ots_

Re: [ADMIN] CESTLOG: statistics buffer is full

2007-04-23 Thread Tom Lane
"Achakzai, Omar" <[EMAIL PROTECTED]> writes: > The message "CESTLOG: statistics buffer is full" appears repeatedly in the= > logfile of the database. You might want to put a space at the end of your log_line_prefix. > How can we solve the problem? I think the only real solution is to update to

Re: [ADMIN] pg_dump and pg_restore with different owners

2007-04-23 Thread Tom Lane
Jaume Sabater <[EMAIL PROTECTED]> writes: >> But I got these errors: >> >> pg_restore: [archiver (db)] Error while PROCESSING TOC: >> pg_restore: [archiver (db)] Error from TOC entry 3751; 0 0 COMMENT >> SCHEMA public postgres >> pg_restore: [archiver (db)] could not execute query: ERROR: must b

[ADMIN]

2007-04-23 Thread Thomas F. O'Connell
On Apr 23, 5:36 am, [EMAIL PROTECTED] ("Simon Riggs") wrote: > On Wed, 2007-04-18 at 18:11 -0500, Thomas F. O'Connell wrote: > > Wanting a nice test of restartable recovery and pg_standby in a warm > > standby server scenario I'm testing, today I pulled the plug on the > > box where I was using

Re: [ADMIN] pg_standby, Restartable Recovery after Hard Failure

2007-04-23 Thread Thomas F. O'Connell
On Apr 23, 5:36 am, [EMAIL PROTECTED] ("Simon Riggs") wrote: > On Wed, 2007-04-18 at 18:11 -0500, Thomas F. O'Connell wrote: > > Wanting a nice test of restartable recovery and pg_standby in a warm > > standby server scenario I'm testing, today I pulled the plug on the > > box where I was using

[ADMIN] Regarding WAL

2007-04-23 Thread Mageshwaran
Hi , I want to do replication using WAL , please tell the methods by which log shipping is done ie moving the wal files to slaves and executing it. ** DISCLAIMER ** Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only

Re: [ADMIN] pl/pgsql function spikes CPU 100%

2007-04-23 Thread Jeff Frost
On Fri, 16 Mar 2007, Jeff Frost wrote: On Fri, 16 Mar 2007, Jeff Frost wrote: On Fri, 16 Mar 2007, Tom Lane wrote: Jeff Frost <[EMAIL PROTECTED]> writes: ... Interestingly, when you strace the backend, it doesn't appear to be doing too much...here's some sample output: select(0, NULL, NU

Re: [ADMIN] pl/pgsql function spikes CPU 100%

2007-04-23 Thread Tom Lane
Jeff Frost <[EMAIL PROTECTED]> writes: > Well, finally got this system upgraded to 8.1.8, but unfortunately, that did > not resolve this. Is there any reasonable way to see where this function is > spending it's time? I've grown enamored of oprofile lately --- if you're on a recent Linux system