On Wed, Apr 18, 2018 at 7:06 PM, Alvaro Herrera <alvhe...@alvh.no-ip.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
frozen_v2.patch
Description: Binary data
