Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Date: 2016-04-15 17:42:34
Message-ID: CA+TgmobdoxPLYEW5BDSTOmQNsi5acGnG-Zb5c1BsWEj29K_5rA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, Apr 14, 2016 at 1:39 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> At 2016-04-12 09:00:57 -0400, robertmhaas(at)gmail(dot)com wrote:
>>
>> On Mon, Apr 11, 2016 at 1:17 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> >
>> > 3) Actually handle the case of the last open segment not being
>> > RELSEG_SIZE properly in _mdfd_getseg() - mdnblocks() does so.
>>
>> #3 seems like it's probably about 15 years overdue, so let's do that
>> anyway.
>
> Do I understand correctly that the case of the "last open segment"
> (i.e., the one for which mdfd_chain == NULL) not being RELSEG_SIZE
> (i.e., _mdnblocks(reln, forknum, v) < RELSEG_SIZE) should not call
> _mfdf_openseg on nextsegno if behaviour is not EXTENSION_CREATE or
> InRecovery?
>
> And that "We won't create segment if not existent" should happen, but
> doesn't only because the next segment file wasn't removed earlier, so
> we have to add an extra check for that case?
>
> In other words, is something like the following what's needed here, or
> is there more to it?

Something like that is what I was thinking about, but I notice it has
the disadvantage of adding lseeks to cater to a shouldn't-happen
condition. Not sure if we should care.

My attempts to test things were also singularly unrewarding. Even
after messing with the filesystem in various ways, I couldn't figure
out exactly how this makes a difference.

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message joris.vandyck 2016-04-15 18:59:02 BUG #14087: btree_gin index doesn't work on INT with POSITIVE constraint
Previous Message Christoph Berg 2016-04-15 15:01:12 Re: BUG #14033: cross-compilation to ARM fails

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-04-15 17:44:27 Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Previous Message Tom Lane 2016-04-15 17:12:07 Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.