On Mon, Oct 31, 2005 at 05:27:15PM -, John Sidney-Woollett wrote:
> > Wonder if it would be a good idea for the error messages to identify which
> > databases might have lost data.
> >
> > However if you have a fair number of databases involved you might get a
> > fair number of log messages. S
Lincoln Yeoh said:
> At 07:48 PM 10/30/2005 +, John Sidney-Woollett wrote:
>
>>"Panic" - that's my middle name. ;)
>>
>>Had I known how to identify the database at fault, and that it would have
>>had no effect on the other databases, then I would have handled this
>>episode differently.
>
> Won
At 07:48 PM 10/30/2005 +, John Sidney-Woollett wrote:
"Panic" - that's my middle name. ;)
Had I known how to identify the database at fault, and that it would have
had no effect on the other databases, then I would have handled this
episode differently.
Wonder if it would be a good idea
"Panic" - that's my middle name. ;)
Had I known how to identify the database at fault, and that it would
have had no effect on the other databases, then I would have handled
this episode differently.
In the event, things seem to be OK. Our old slave db is now acting as
master and the old mas
Martijn
Thanks for the answers/thoughts...
Vacuumuming the databases hammers the server so the vacuums are spread
out at different times during the night/morning. Plus template1 is
vacuumed once a week.
I guess I was unlucky to have missed the vacuum on that unused database
(due to my misun
John Sidney-Woollett <[EMAIL PROTECTED]> writes:
> Just out of curiousity would the wraparound error (for mail_lxtreme)
> actually have affected data in bp_live?
> Could I just have deleted mail_lxtreme and then continued to use bp_live
> as though nothing had happened?
No, and yes, which is why
On Sun, Oct 30, 2005 at 06:41:45PM +, John Sidney-Woollett wrote:
> Hmm. I'm pretty sure that database mail_lxtreme was unused (no
> connections/activity) - I didn't think that it would need to be vacuumed
> at all...
A database that is never used still needs to be vacuumed. The only
excepti
Hmm. I'm pretty sure that database mail_lxtreme was unused (no
connections/activity) - I didn't think that it would need to be vacuumed
at all...
Just out of curiousity would the wraparound error (for mail_lxtreme)
actually have affected data in bp_live?
Could I just have deleted mail_lxtrem
John Sidney-Woollett <[EMAIL PROTECTED]> writes:
> OK, I restored the pgsql/data to another server and started up postgres
> and this is what I got:
> SELECT datname, age(datfrozenxid) FROM pg_database;
> datname| age
> --+-
> mail_lxtreme | -2074187459
>
OK, I restored the pgsql/data to another server and started up postgres
and this is what I got:
SELECT datname, age(datfrozenxid) FROM pg_database;
datname| age
--+-
mail_lxtreme | -2074187459
bp_live | 1079895636
template1| 1076578064
template0
John Sidney-Woollett <[EMAIL PROTECTED]> writes:
> 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...
Importing a dump will tell you nothing at al
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/
John Sidney-Woollett <[EMAIL PROTECTED]> 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 t
Martin, thanks for the feedback.
I had a look around and couldn't see any data loss (but wasn't really
sure where to start looking).
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
On Sun, Oct 30, 2005 at 08:50:18AM +, John Sidney-Woollett wrote:
> Oh my god!
>
> DB is pg 7.4.6 on linux
Firstly, check pg_database, it should tell you which databases need to
be vacuumed. Any database you regularly vacuumed is fine so maybe the
corruption is in some other database you
Oh my god!
DB is pg 7.4.6 on linux
2005-10-27 05:55:55 WARNING: some databases have not been vacuumed in
2129225822 transactions
HINT: Better vacuum them within 18257825 transactions, or you may have
a wraparound failure.
2005-10-28 05:56:58 WARNING: some databases have not been vacu
16 matches
Mail list logo
