Anssi Kääriäinen wrote:
> I tried to break the version 11 of the patch (some of the work was
> against earlier versions). In total I have used a full work day
> just trying to break things, but haven't been able to find anything
> after version 8. I can verify that the partial index issue is
> fixed, and the count(*) performance is a lot better now.
Thanks for all your testing!
For the record, Dan found one more issue with the placement of our LW
locking statements which provided a very small window for one process
to see an uninitialized structure from another. He found it by
uncommenting the '#define TEST_OLDSERXID' line (thereby forcing any
terminated transaction immediately into the SLRU logic) and letting
DBT-2 pound on it for a long time. If anyone else is going to be
doing heavy stress testing, you might want to apply this fix:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=036eefe05ba58da6dff9e1cae766e565182f37be
The issue is sufficiently hard to hit that I didn't want to post a
whole new patch for it. I've been considering it now that doc
changes are complete, but am waiting to see how the 2PC work is
going.
> One thing I have been thinking about is how does predicate locking
> indexes work when using functional indexes and functions marked as
> immutable but which really aren't. I don't know how predicate
> locking indexes works, so it might be that this is a non-issue.
As David pointed out, doing that is likely to cause you bigger
headaches than this; but yes, you can break serializability by
declaring a non-immutable function as immutable and then using it on
a permanent table. Like David apparently is, I'm skeptical that this
merits specific mention in the docs; but I'm open to arguments to
the contrary -- particularly if they suggest what language to put
where.
-Kevin