On Wed, Mar 15, 2017 at 9:18 AM, Stephen Frost <sfr...@snowman.net> wrote: >> I think we have sufficient comments in code especially on top of >> function _hash_alloc_buckets(). > > I don't see any comments regarding how we have to be sure to handle > an out-of-space case properly in the middle of a file because we've made > it sparse. > > I do see that mdwrite() should handle an out-of-disk-space case, though > that just makes me wonder what's different here compared to normal > relations that we don't have an issue with a sparse WAL'd hash index but > we can't handle it if a normal relation is sparse.
I agree. I think that what hash indexes are doing here is inconsistent with what we do for btree indexes and the heap. And I don't think it would be bad to fix that. We could, of course, go the other way and do what Tom is suggesting - insist that everybody's got to be prepared for sparse files, but I would view that as something of a U-turn. I think hash indexes are like this because nobody's really worried about hash indexes because they haven't been crash-safe or performant. Now that we've made them crash safe and are on the way to making them performant, fixing other things is, as Tom already said, a lot more interesting. Now, that having been said, I'm not sure it's a good idea to tinker with the behavior for v10. We could change the new-splitpoint code so that it loops over all the pages in the new splitpoint and zeroes them all, instead of just the last one. If we all agree that's how it should work, then it's probably not a lot of work to make the change. But if what's needed is anything more than that or we don't all agree, then we'd better just leave it alone and we can revisit it for v11. It's too late to start making significant or controversial design changes at this point, and you could argue that this is a preexisting design defect which the WAL-logging patch wasn't necessarily obligated to fix. -- 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