On Sat, Mar 26, 2016 at 8:39 AM, Andres Freund <and...@anarazel.de> 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?
Well, I agree that it's pretty strange that _mdfd_getseg() makes no such check, but I still don't think I understand what's going on here. Backends shouldn't be requesting nonexistent blocks from a relation - higher-level safeguards, like holding AccessExclusiveLock before trying to complete a DROP or TRUNCATE - are supposed to prevent that. If this patch is causing us to hold onto smgr references to a relation on which we no longer hold locks, I think that's irretrievably broken and should be reverted. I really doubt this will be the only thing that goes wrong if you do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers