From a review of recent emails I've put together a list of what I'm
going to try to do this evening, in order of attack. It's ambitious
and I may well not get to the end tonight, but I wanted to get the
issues on record in list form. If someone spots one I'm missing or
thinks I should change the order I go at them, please say something.
Based on the feedback, I suspect that (1) is a beta2 blocker. I
don't think the rest are, although it would sure be nice to get them
in now.
If anyone else wants to jump on something on this list, let me know
-- I'm happy to share.
(1) Pass snapshot in to some predicate.c functions. The particular
functions have yet to be determined, but certainly any which acquire
predicate locks, and probably all which are guarded by the
SkipSerialization() macro. Skip processing for non-MVCC snapshots.
The goal here is to reduce false positive serialization failures and
avoid confusion about locks showing in the pg_locks view which are
hard to explain.
(2) Check on heap truncation from vacuum. On the face of it this
seems unlikely to be a problem since we make every effort to clean
up predicate locks as soon as there is no transaction which can
update what a transaction has read, but it merits a re-check. Once
confirmed, add a note to lazy_truncate_heap about why it's not an
issue.
(3) Add regression tests for SSI/DDL interaction.
(4) Add a comment to the docs about how querying tuples by TID
doesn't lock not-found "gaps" the way an indexed access would.
(5) I've also had a note to myself to add a couple more bullets to
the performance notes at the bottom of this section:
http://developer.postgresql.org/pgdocs/postgres/transaction-iso.html#XACT-SERIALIZABLE
- If you're having a lot of rollbacks due to table-scan plans being
used, you might want to try reducing random_page_cost and/or
boosting cpu_tuple_cost.
- If you're having a lot of rollbacks because multiple locks are
being combined into relation locks, you might want to increase
max_pred_locks_per_transaction.
-Kevin