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
pg_check_frozen() reports corrupted VM freeze state.
Found with one of my stress tests. Simplified to the repro below.
The reason for the 33 rows/pages is that I wanted to test if a 2nd vacuum
freeze repaired the situation. I was confounded till I discovered
SKIP_PAGES_THRESHOLD was 32.
My
