Re: Breakage with VACUUM ANALYSE + partitions

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Breakage with VACUUM ANALYSE + partitions
Date: 2016-03-31 05:22:20
Message-ID: 20160331052220.GA1504920@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sat, Mar 26, 2016 at 01:39:42PM +0100, Andres Freund wrote:
> On 2016-03-25 12:02:05 -0400, Robert Haas wrote:
> > Gosh, that's surprising. I wonder if that just revealed an underlying
> > issue rather than creating it.
>
> I think that's the case; it's just somewhat unlikely to hit in other
> cases.
>
> If SMgrRelation->md_fd[n] is an empty relation, and mdread() or another
> routine is asking for a block in the second segment - which will error
> out. But even if the first segment is zero bytes, _mdfd_getseg() will
> dutifully try to open the second segment. Which will succeed in the case
> of a truncated relation, because we leave the truncated segment in
> place.
>
> ISTM that _mdfd_getseg better check the length of the last segment
> before opening the next one?

[This is a generic notification.]

The above-described topic is currently a PostgreSQL 9.6 open item. Andres,
since you committed the patch believed to have created it, you own this open
item. If that responsibility lies elsewhere, please let us know whose
responsibility it is to fix this. Since new open items may be discovered at
any time and I want to plan to have them all fixed well in advance of the ship
date, I will appreciate your efforts toward speedy resolution. Please
present, within 72 hours, a plan to fix the defect within seven days of this
message. Thanks.

Non-generic addendum: granted, s/created/unearthed/ is looking more precise.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jarosław Stokłosa 2016-03-31 07:49:00 Re: BUG #14046: Bad mathematical rules for 0 cast
Previous Message Jeff Janes 2016-03-30 22:18:01 Re: BUG #14051: GIN index creation fails with large number of duplicate keys

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajkumar Raghuwanshi 2016-03-31 05:35:37 Re: Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result
Previous Message Noah Misch 2016-03-31 05:16:33 Re: Performance degradation in commit 6150a1b0