Hi Jeff, On Mon, Dec 29, 2014 at 2:29 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > Using the vallock2 version of V1.8, using the test I previously described, I > get some all-null rows, which my code should never create. Also, the index > and table don't agree, in this example I find 3 all-null rows in the table, > but only 2 in the index. I've attached an example output of querying via > index and via full table scan, and also the pageinspect output of the blocks > which have the 3 rows, in case that is helpful.
Interesting. Thanks a lot for your help! > This was just a straight forward issue of firing queries at the database, > the crash-inducing part of my test harness was not active during this test. > I also ran it with my crashing patch reversed out, in case I introduced the > problem myself, and it still occurs. > > Using V1.7 of the vallock2 patch, I saw the same thing with some all-null > rows. I also saw some other issues where two rows with the same key value > would be present twice in the table (violating the unique constraint) but > only one of them would appear in the index. I suspect it is caused by the > same issue as the all-null rows, and maybe I just didn't run v1.8 enough > times to find that particular manifestation under v1.8. This is almost certainly a latent bug with approach #2 to value locking, that has probably been there all along. Semantics and syntax have been a recent focus, and so the probability that I introduced a regression of this nature in any recent revision seems low. I am going to investigate the problem, and hope to have a diagnosis soon. Once again, thanks! -- 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
