If the index bloat is fixed (we haven't seen firm evidence one way or
'tother yet) AND you were running the pg_autovacuum daemon by default,
then that would get you there.
I wonder if it's possible to have the pg_autovacuum daemon eventually move
into the core once it's tested, so that a simple GUC setting will turn it
on or off? Is that part of the eventual plan?
On Wed, 29 Oct 2003, Joshua D. Drake wrote:
> This paragraph:
>
> HIGH AVAILABILITY
> Expansion of PostgreSQL's Free Space Map disk management feature to support
> continuous index maintenance is the last "piece of the puzzle" in providing
> 24/7/365 uptime for PostgreSQL databases. The many hardware solutions vendors
> who include PostgreSQL as the embedded database in their applications may now
> eliminate the need for any data locking or downtime in their applications.
>
>
> I believe is false. As long as you have to vacuum the above is not true. Also
> as long as their is a potential that we have to use the reindex command the above
> isn't true. Anything that the "system" requires (which does not include transactions)
> that causes a lock for any period of time would invalidate the above.
>
> Sincerely,
>
> Joshua Drake
>
>
>
> Josh Berkus wrote:
>
> >Guys,
> >
> >First off: The release mentions eRServer in passing, in the context of
> >"high-availablity enterprise postgres". So I don't think that needs to be
> >changed.
> >
> >For the Press Kit, where the more substantial mention is, we have 3 choices:
> >
> >1) Delete the paragraph;
> >2) Move the paragraph "down" thus reducing its priority
> >3) leave things the way they are.
> >
> >
> >
>
>
