On Fri, May 27, 2016 at 10:18 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Fri, May 27, 2016 at 9:58 AM, Kevin Grittner <kgri...@gmail.com> wrote: >> On Tue, May 24, 2016 at 4:56 PM, Andres Freund <and...@anarazel.de> wrote: > >>> If an old session with >= repeatable read accesses a clustered >>> table (after the cluster committed), they'll now not see any >>> errors, because all the LSNs look new. >> >> Again, it is new LSNs that trigger errors; if the page has not been >> written recently the LSN is old and there is no error. I think you >> may be seeing problems based on getting the basics of this >> backwards. > > I am reviewing the suggestion of a possible bug now, and will make > it my top priority until resolved. By the end of 1 June I will > either have committed a fix or posted an explanation of why the > concern is mistaken, with test results to demonstrate correct > behavior.
This got set back by needing to fix a bug in the 9.5 release. I am back on this and have figured out that everyone who commented on this specific issue was wrong about a very important fact -- the LSNs in index pages after CREATE INDEX (with or without CONCURRENTLY) and for REINDEX are always == InvalidXLogRecPtr (0). That means that a snapshot from before an index build does not always generate errors when it should on the use of the new index. (Any early pruning/vacuuuming from before the index build is missed; activity subsequent to the index build is recognized.) Consequently, causing the index to be ignored in planning when using the old index is not a nice optimization, but necessary for correctness. We already have logic to do this for other cases (like HOT updates), so it is a matter of tying in to that existing code correctly. This won't be all that novel. I now expect to push a fix along those lines by Tuesday, 6 June. -- Kevin Grittner EDB: 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
