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.
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 |
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 |