On Fri, Mar 11, 2016 at 8:19 AM, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > I do hope that my patch will be accepted in 9.6, so this conflict looks > really bad.
I hope so too. I'll have to look into this issue. > I think that error is caused by changes in pages layout. To save some space > nonkey attributes are truncated > when btree copies the indexed value into inner pages or into high key. You > can look at index_reform_tuple() calls. That seems like the kind of problem that would be expected when things like that change. I think it's going to be hard to add new B-Tree features without a tool like this, which was a big reason to work on it; to make these new projects possible to test and review. I see many opportunities to improve the B-Tree code, just as I imagine you do. These projects are quite strategically important, because B-Trees are so frequently used. I think that Postgres B-Trees produce excessive random I/O for checkpoints for various reasons, and this disadvantages Postgres when it is compared to other major systems. As things get better in other areas of Postgres, these hard problems become more important to solve. > I wonder, whether you can add some check of catalog version to your module > or this case requires more changes? I think that it's just going to be tied to the Postgres version. So, if your B-Tree patches are committed first, it's on me to make sure they're handled correctly. Or vice-versa. Not worried that that will be a problem. We already take special steps to avoid the "minus infinity" item on internal pages. I think that in the future, if Postgres B-Trees get suffix truncation for internal page items, there are new problems for amcheck (suffix truncation remove unneeded information from internal page items, sometimes greatly increasing B-Tree fan-out. Internal page items need only be sufficient to guide index scans correctly.). Specially, with suffix truncation there might be "minus infinity" *attributes*, too (these could make it safe to completely remove attributes/columns past the first distinguishing/distinct attribute on each item on internal pages). That's a case that amcheck then needs to care about, just like it currently cares about the existing concept of minus infinity items. That's how it goes for amcheck. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers