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.
Thanks
John
Tom Lane wrote:
John Sidney-Woollett <johnsw@xxxxxxxxxxxxx> 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
from.
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
