Re: [BUGS] Breakage with VACUUM ANALYSE + partitions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Date
Msg-id CA+Tgmob97m0GniMp82bGkzdZBuLbJWBy2uUbJMtDpAHbm8CRVQ@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Andres Freund <andres@anarazel.de>)
Responses Re: [BUGS] Breakage with VACUUM ANALYSE + partitions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Apr 25, 2016 at 4:57 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-04-25 16:29:36 -0400, Robert Haas wrote:
>> On Mon, Apr 25, 2016 at 2:05 PM, Andres Freund <andres@anarazel.de> wrote:
>> > Well, I posted a patch. I'd have applied it too (after addressing your
>> > comments obviously), except that there's some interdependencies with the
>> > nsmg > 0 thread (some of my tests fail spuriously without that
>> > fixed). Early last week I waited for a patch on that thread, but when
>> > that didn't materialize by Friday I switched to work on that [1].  With
>> > both fixes applied I can't reproduce any problems anymore.
>>
>> OK.  What are the interdependencies?  You've said that a few times but
>> I am not clear on what the nature of those interdependencies is.
>
> I added checks to smgr/md.c that verify that the smgr state is
> consistent with the on-file state. Without the two issues in [1] fixed,
> these tests fail in a standby, while running regression tests.  Adding
> those tests made me notice a bug in an unreleased version of the patch,
> so it seems they're worthwhile to run.

Footnote [1] is used, but not defined.

>> >> I assume you will be pretty darned unhappy if we end up at #2, so I am
>> >> trying to figure out if we can achieve #1.  OK?
>> >
>> > Ok.
>>
>> I'm still not clear on the answer to this.  I think the answer is that
>> you think that this patch is OK to commit with some editing, but the
>> situation with the nmsgs > 0 patch is not so clear yet because it
>> hasn't had any review yet.  And they depend on each other somehow.  Am
>> I close?
>
> You are. I'd prefer pushing this after fixes for the two invalidation
> issues, because it makes testing easier. But I guess the timeframe there
> is unclear enough, that it makes sense to test this patch on top of the
> the preliminary fixes, and then push without those.

I think it makes sense to go ahead and push this fix rather soon.  I'd
much rather not have this bug, even if verifying that I don't have it
is a little harder than it might be under other circumstances.  The
fix could be buggy too, and if that fix doesn't go in until right
before we ship beta1, we're less likely to be able to find and correct
any deficiencies before that goes out the door.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposed change to make cancellations safe
Next
From: Andres Freund
Date:
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions