SSI work for 9.1
От | Kevin Grittner |
---|---|
Тема | SSI work for 9.1 |
Дата | |
Msg-id | 4DEFB5EA020000250003E3C3@gw.wicourts.gov обсуждение исходный текст |
Ответы |
Re: SSI work for 9.1
|
Список | pgsql-hackers |
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 rollbacksdue 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
В списке pgsql-hackers по дате отправления: