Re: Help me recovering data

From: Russell Smith <mr-russ(at)pws(dot)com(dot)au>
To: Kevin Brown <kevin(at)sysexperts(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Help me recovering data
Date: 2005-02-18 11:00:53
Message-ID: 200502182200.53550.mr-russ@pws.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 18 Feb 2005 04:38 pm, Kevin Brown wrote:
> Tom Lane wrote:
> > Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
> > > BTW, why not do an automatic vacuum instead of shutdown ? At least the
> > > DB do not stop working untill someone study what the problem is and
> > > how solve it.
> >
> > No, the entire point of this discussion is to whup the DBA upside the
> > head with a big enough cluestick to get him to install autovacuum.
> >
> > Once autovacuum is default, it won't matter anymore.
>
> I have a concern about this that I hope is just based on some
> misunderstanding on my part.
>
> My concern is: suppose that a database is modified extremely
> infrequently? So infrequently, in fact, that over a billion read
> transactions occur before the next write transaction. Once that write
> transaction occurs, you're hosed, right? Autovacuum won't catch this
> because it takes action based on the write activity that occurs in the
> tables.
>
> So: will autovacuum be coded to explicitly look for transaction
> wraparound, or to automatically vacuum every N number of transactions
> (e.g., 500 million)?
>
autovacuum already checks for both Transaction wraparound, and table updates.
It vacuums individual tables as they need it, from a free space/recovery point of view.

It also does checks to ensure that no database is nearing transaction wraparound, if it
is, it initiates a database wide vacuum to resolve that issue.

Regards

Russell Smith
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Russell Smith 2005-02-18 11:02:03 Re: Help me recovering data
Previous Message Neil Conway 2005-02-18 10:33:56 Re: win32 performance - fsync question