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:[email protected]]
> 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
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 problem hasn't
changed much though - we still don't use the database 'p
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!
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:
13 matches
Mail list logo
