Skip site navigation (1) Skip section navigation (2)

Re: Please HELP - URGENT - transaction wraparound error

From: John Sidney-Woollett <johnsw(at)wardbrook(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>,pgsql-general(at)postgresql(dot)org
Subject: Re: Please HELP - URGENT - transaction wraparound error
Date: 2005-10-30 16:24:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Hi Tom

You're not wrong about panicking! This is the worst Sunday I've had in a 
while... No sunday lunch or time with the kids... :(

This database supports a (normally 24/7) website and we couldn't 
tolerate any possibility of data corruption. I had to make a judgement 
call on preventing any/further data loss or corruption, and switching 
over to the slave seemed the safest thing to do (based on my ignorance 
of the wraparound problem).

I can restore the file system backup of pgsql/data to another database 
server and then get the info from pg_database. Or I can import a dump 
file from 15 minutes before I re-inited the database...

What exactly am I looking for though?

We don't use OIDs when creating tables...

Could Slon 1.1.0 be causing a problem for us? It must be creating and 
deleting bucket loads of records as part of its regular activity...

What am I likely to have missed in my vacuuming? Because whatever I did 
wrong is going to break our current live database at some point soon.



Tom Lane wrote:
> John Sidney-Woollett <johnsw(at)wardbrook(dot)com> writes:
>>I decided to switch over to the slave which is now our live database. 
>>the old master with the problem has already been re-inited (although I 
>>have a cold backup of the data dir), plus dump files that I can restore 
> You panicked much too quickly and destroyed the evidence ... unless by
> "cold backup" you mean a filesystem backup, in which case what you
> should do is restore that and take a look at what's in its pg_database.
> I think there's no question that there is some omission in your vacuuming
> procedures, and you need to find out what it is.
> 			regards, tom lane

In response to


pgsql-general by date

Next:From: Tom LaneDate: 2005-10-30 16:31:43
Subject: Re: Sorting problems with SELECT * FROM table WHERE name LIKE 'Ö%'
Previous:From: David FetterDate: 2005-10-30 16:24:01
Subject: Re: mysql replace in postgreSQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group