Hi!
After going several months without such incidents, we now got bit by the same problem again. We have since upgraded the
hardwarewe ran the database cluster on and currently use version 8.3.7. The general outline of the problem hasn't
changedmuch though - we still don't use the database 'postgres' except for one lone pgagent-job which has only been
configureda couple of weeks back and we do a nightly vacuum over all databases in addition the the running of the
autovacuumdaemon. As I expect that this might hit again in a couple of months: Any suggestions on what sort of forensic
datamight be required to actually find out the root of what's causing it? As I needed to get the cluster back up and
runningagain, I used the same remedy as last time and simply dropped the database and recreated it from template1, so
there'snot much left to be looked into right now, but if I knew what kind of data to retain I mit be able to come up
withsome more useful info next time...
Kind regards
Markus
> -----Ursprüngliche Nachricht-----
> Von: Markus Wollny
> Gesendet: Freitag, 21. März 2008 23:34
> An: 'Tom Lane'
> Cc: pgsql-general@postgresql.org
> Betreff: AW: [GENERAL] Transaction wraparound problem with
> database postgres
>
> Tom Lane wrote:
> > "Markus Wollny" <Markus.Wollny@computec.de> writes:
> >> I'd still like to find out what exactly happened here so I can
> >> prevent the same from happening again in the future.
> >
> > Me too. It would seem that something did a vacuum of
> postgres with a
> > strange choice of xid cutoff, but I can't think of what would cause
> > that.
> >
> > Do you ever do VACUUM FREEZE on your databases?
>
> No, I actually never heard of VACUUM FREEZE, I have to admit.
>
Computec Media AG
Sitz der Gesellschaft und Registergericht: Fürth (HRB 8818)
Vorstandsmitglieder: Albrecht Hengstenberg (Vorsitzender) und Rainer Rosenbusch
Vorsitzender des Aufsichtsrates: Jürg Marquard
Umsatzsteuer-Identifikationsnummer: DE 812 575 276
