"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> two last questions about the transaction ID wraparound problem of my DBs I had
> yesterday (see former postings). After applying the 'recovery procedure' Tom
> suggested now my XIDs are looking almost fine again, except for the template0
> DB.
You
Hello,
two last questions about the transaction ID wraparound problem of my DBs I had
yesterday (see former postings). After applying the 'recovery procedure' Tom
suggested now my XIDs are looking almost fine again, except for the template0
DB.
dev_db=# SELECT datname, age(datfrozenxid) FROM pg_d
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> On May 11, 2:39pm, Tom Lane wrote:
>> If it does, go ahead and do a database-wide plain VACUUM, and you
>> should be OK.
> Done. As far as I can tell, everything is OK again.
Sweet ;-) In the words of my former business partner, a private pilot
P.S.:A TODO for me: CRON Script for weekly VACUUM ;)
on heavy use databases, mine generally does a light vacuum every 4 hours, and a
once a day full on everything. also, a weekly full reindex on a really really
heavy use systems like this one message board server I ad-mangle
something like...
Hi,
On May 11, 2:39pm, Tom Lane wrote:
> What I would recommend as a first step is to stop the postmaster and
> then take a tarball backup of the entire $PGDATA tree. This will at
> least provide a chance to go back if subsequent tries mess things up
> completely.
Done. This was probably the
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> The 6 completely lost tables are not so dramatical, because they contain only
> static data, that I can restore from the development system. But what happens
> with the 8 tables that are still accessable, but not listed in pg_tables,
> after
> a V
everal monthes
ago.
> Further on we use transactions at several places and we have at least 20
> transactions per minute.
>
> Does now a normal VACUUM FULL of the whole DB(s) fix our problem?
>
> Michael
>
>
> On May 11, 11:51am, Tom Lane wrote:
> > Subject: Re:
he whole DB(s) fix our problem?
Michael
On May 11, 11:51am, Tom Lane wrote:
> Subject: Re: [BUGS] Missing tables in postgresql 7.2.4
> "Michael Beckstette" <[EMAIL PROTECTED]> writes:
> > we recently discovered on our production database an a little bit bizarre
> > pro
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> we recently discovered on our production database an a little bit bizarre
> problem (after two years stable operations). Some tables are simply missing,
> or
> sometimes the affected table(s) is/are there but not listed in pg_tables.
This sounds
