On Sun, Mar 7, 2010 at 6:06 PM, Markus Wollny wrote:
> Hi!
>
> After going several months without such incidents, we now got bit by the same
> problem again. We have since upgraded the hardware we ran the database
> cluster on and currently use version 8.3.7. The general outline of the
> proble
Hi!
> From: Scott Marlowe [mailto:scott.marl...@gmail.com]
> Do your logs show any kind of error when vacuuming about
> "only owner can vacuum" a table or anything?
I grepped through the logs from the last four days and, no, there were
none such errors whatsoever. Last vacuum analyze run retu
On Sun, Mar 7, 2010 at 6:06 PM, Markus Wollny wrote:
> Hi!
>
> After going several months without such incidents, we now got bit by the same
> problem again. We have since upgraded the hardware we ran the database
> cluster on and currently use version 8.3.7. The general outline of the
> proble
27;
> Cc: pgsql-general@postgresql.org
> Betreff: AW: [GENERAL] Transaction wraparound problem with
> database postgres
>
> Tom Lane wrote:
> > "Markus Wollny" writes:
> >> I'd still like to find out what exactly happened here so I can
> >> prevent t
Tom Lane wrote:
> "Markus Wollny" <[EMAIL PROTECTED]> 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 ca
Andreas 'ads' Scherbaum wrote:
> Hello,
> First of all, it would help you and most of the readers on this list,
> if you have the error messages in english. There is a german
> mailinglist too, if you want to ask in german.
Sorry, I tried to describe the issue as best as I could and included the
"Markus Wollny" <[EMAIL PROTECTED]> writes:
> Sorry for the quick updates to my own messages, but I didn't want to
> lean back and wait - so I took to more aggressive measures. All my
> other databases in this cluster are fine - and the 'postgres' database
> doesn't seem to do anything really usefu
Hi!
Thanks for all the quick replies :)
Tom Lane wrote:
> "Markus Wollny" <[EMAIL PROTECTED]> writes:
>> Just some more info, hoping that it helps with a diagnosis:
>
>> 1: datname (typeid = 19, len = 64, typmod = -1, byval = f)
>> 2: age (typeid = 23, len = 4, typmod = -1, byval =
Hi!
Sorry for the quick updates to my own messages, but I didn't want to lean back
and wait - so I took to more aggressive measures. All my other databases in
this cluster are fine - and the 'postgres' database doesn't seem to do anything
really useful except being the default database. I drop
"Markus Wollny" <[EMAIL PROTECTED]> writes:
> Just some more info, hoping that it helps with a diagnosis:
> 1: datname (typeid = 19, len = 64, typmod = -1, byval = f)
> 2: age (typeid = 23, len = 4, typmod = -1, byval = t)
> 3: datfrozenxid(typeid = 28, len = 4, typ
Hello,
On Fri, 21 Mar 2008 21:50:57 +0100 Markus Wollny wrote:
> My database cluster has just stopped working. I get the following message:
> psql: FATAL: Datenbank nimmt keine Befehle an, um Datenverlust in Datenbank
> »postgres« wegen Transaktionsnummernüberlauf zu vermeiden
> TIP: Halten S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 21:50:57 +0100
"Markus Wollny" <[EMAIL PROTECTED]> wrote:
> That's what I just did, but the problem persists. Whenever I issue a
> 'vacuum', the number of transactions simply decreases.
>
> This is PostgreSQL 8.2.4 on x86_64-unkn
Hi!
My database cluster has just stopped working. I get the following message:
psql: FATAL: Datenbank nimmt keine Befehle an, um Datenverlust in Datenbank
»postgres« wegen Transaktionsnummernüberlauf zu vermeiden
TIP: Halten Sie den Postmaster an und verwenden Sie ein Standalone-Backend, um
V
Hi!
Just some more info, hoping that it helps with a diagnosis:
1: datname (typeid = 19, len = 64, typmod = -1, byval = f)
2: age (typeid = 23, len = 4, typmod = -1, byval = t)
3: datfrozenxid(typeid = 28, len = 4, typmod = -1, byval = t)
1:
14 matches
Mail list logo
