Re: VM map freeze corruption

On Wed, Apr 18, 2018 at 7:06 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

>
>
> IMO the cause is the totally_frozen variable, which starts life in a
> bogus state (true) and the different code paths can set it to the right
> state, or by inaction end up deciding that the initial bogus state was
> correct in the first place. Errors of omission are far too easy in that
> kind of model, ISTM, so I propose this slightly different patch, which
> albeit yet untested seems easier to verify and easier to get right.
>

I wonder if we should just avoid initialising those variables at the top
and take compiler's help to detect any missed branches. That way, we shall
know exactly why and where we are making them true/false. I also think that
we should differentiate between scenarios where xmin/xmax is already frozen
and scenarios where we are freezing them now.

I come up with attached. Not fully polished (and there is a XXX that I left
for comments), but hopefully enough to tell what I am thinking. Do you
think it's any improvement or actually makes the problem worse?

Thanks,
Pavan

--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services