Re: [ADMIN] Is there a "Just Kidding" command?

can stop, then I can start it up again. Also, > other requests are now being denied... > > Here’s hoping. Maybe the “doh!!” command? > > /r/b > > Robert Burgholzer > Surface Water Modeler > Virginia DEQ Office of Surface and Ground Water Supply > 804-869-3066 > &

Re: [ADMIN] unexpected EOF on client connection during pg_dumpall

FWIW - if you are looking at a backup approach with the dumpall, I have found that using a rsync to just mirror the file system is wy faster, and hence less prone to interuption. This is how it is recommended with a warm standby development, and works great, and also is far less consumptiv

Re: [ADMIN] Setting up streaming replication w/ a big ole database

I've definitely done this, albeit with a 6-7 GB database. I had accomplished previous backups with pg_dump commands, that invariably had to be restarted and took DAYS to complete. The rsync method achieved the backup within hours the first time, and you can do subsequent backups in minutes (in ca

Re: [ADMIN] diagnosing a db crash - server exit code 2

wrote: > On 10/03/2011 10:10 AM, Robert Burgholzer wrote: > > FWIW - I am currently trying this while tracing the process that I > > assume is the postmaster (/usr/bin/postgres -D /home/postgres/data), > > since this process number indicates that it was recently restarted - &

Re: [ADMIN] diagnosing a db crash - server exit code 2

Thank Tom, that's much better than guessing. r.b. On Mon, Oct 3, 2011 at 7:10 PM, Tom Lane wrote: > Joe Conway writes: > > On 10/03/2011 10:10 AM, Robert Burgholzer wrote: > >> FWIW - I am currently trying this while tracing the process that I > >> assume is t

Re: [ADMIN] diagnosing a db crash - server exit code 2

Thanks Joe - yeah, I am now tracing the postmaster -- will post up shortly. r.b. On Mon, Oct 3, 2011 at 1:28 PM, Joe Conway wrote: > On 10/03/2011 10:10 AM, Robert Burgholzer wrote: > > FWIW - I am currently trying this while tracing the process that I > > assume is the postm

Re: [ADMIN] diagnosing a db crash - server exit code 2

g Tools: > http://sourceforge.net/projects/npsource/ > > -Original Message- > From: Joe Conway [mailto:m...@joeconway.com] > Sent: Thursday, September 29, 2011 1:30 PM > To: Robert Burgholzer > Cc: Burgholzer, Robert (DEQ); Scott Marlowe; pgsql-admin@postgresql.org &

Re: [ADMIN] diagnosing a db crash - server exit code 2

Just a quick checkin on this problem. Thus far, I have managed to install dbg and recompile postgresql with the appropriate debugging headers/variables. I have been following wiki that Scott sent, and attempted to trace one of my pg processes while making it crash. I have "succeeded" in causing

Re: [ADMIN] Re: Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..."

Tom, Thanks for getting in touch. Unfortunately, I thought to myself "why not drop the db in single mode under database postgres", which I did, and which worked, and thus, I can no longer produce the error, nor can I query the "phantom" table as you suggested. I can say that when I tried to vacuu

[ADMIN] Re: Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..."

t DOES NOT exist any longer. Do I have any recourse other than to drop and rebuild all of my tables? Can I just dump, drop and recreate my database? How do I drop a database in --single mode? Thanks, r.b. On Sun, Oct 10, 2010 at 7:21 AM, Robert Burgholzer wrote: > > ERROR:  database

[ADMIN] Vaccuuming every db in cluster fails to eliminate "execute a full-database VACUUM in..."

So, I have neglected to do the vacuum on every db for a long time, and this is a very high volume cluster. The db stopped executing requests this morning, and reported: ERROR: database is not accepting commands to avoid wraparound data loss in database "vwuds" So, I did some googling and found