On Thu, May 7, 2015 at 11:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> OK, so here is what's in Thomas's latest version that's not already
> committed and different from my last version. It should apply on top
> of my multixact-av.patch, but I attach it here as a separate extract
> for ease of review. I think what we need to determine is whether this
> is the right fix for the problem of starting emergency autovacuums for
> member space exhaustion even when autovacuum=off.
Nope, I extracted that incorrectly. Second try attached.
I think Thomas's question upthread is a very good one:
> See attached patch, based on your multixact-av.patch. With autovacuum
> set to off, it vacuums as expected. I wonder if
> DetermineSafeOdlestOffset is being called in all the right places to
> guarantee that the state is initialised.
It seems to me that the most obvious places where
DetermineSafeOldestOffset() should be called are (1) at startup or
after recovery, to initialize the value; and (2) each time we truncate
the SLRU, to update the value. Other than that, this doesn't change.
The startup calls are there, in apparently reasonable places, but it's
not obvious to me how this gets called in the TruncateMultiXact path.
Instead it seems to get set via the SetMultiXactIdLimit path. Maybe
that's OK, but it would seem to imply that we're OK with overwriting
old members information if that information was slated for truncation
at the next checkpoint anyway, which seems scary. Wouldn't it be
better to only advance the threshold once the checkpoint completes and
the truncation is done?
Maybe I'm misreading something here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
