Pavan Deolasee wrote:
> 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 wh
On Wed, Apr 18, 2018 at 7:06 PM, Alvaro Herrera
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 fir
On Wed, Apr 18, 2018 at 10:36 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
>> On Wed, Apr 18, 2018 at 7:37 AM, Wood, Dan wrote:
>
>> > My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId()
>> > returns FRM_NOOP if the MultiXACT locked rows haven't committed. This
>> > results i
Pavan Deolasee wrote:
> On Wed, Apr 18, 2018 at 7:37 AM, Wood, Dan wrote:
> > My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId()
> > returns FRM_NOOP if the MultiXACT locked rows haven't committed. This
> > results in changed=false and totally_frozen=true(as initialized). When
>
On Wed, Apr 18, 2018 at 7:37 AM, Wood, Dan wrote:
>
>
> My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId()
> returns FRM_NOOP if the MultiXACT locked rows haven't committed. This
> results in changed=false and totally_frozen=true(as initialized). When
> this returns to lazy_scan
