I just finished implementing the SLRU techniques to limit shared
memory usage and provide graceful degradation under pessimal loads
(as suggested by Heikki), Dan seems to be wrapping up work on
preventing non-serializable transactions from being rolled back with
a serialization failure if they split a predicate-locked page at the
point were we're running out of space to allocate predicate locks (as
suggested by Heikki), and John's working on documentation.
We've recently committed documentation for new GUCs, modified
statements, and the new switch on pg_dump. The main things I see
that we still need in documentation are a README.SSI file and some
serious work in mvcc.sgml. I'm going through the old emails to see
what issues people may have raised that might need to be addressed;
besides making the AMs for GIN, GiST, and hash SSI aware (so that
they have fewer false positive rollbacks than with the default
handling), are there any issues people want to be sure I look at
before posting a patch?
Then there's the question of whether to submit it in pieces. There
are going to be big chunks no matter how I slice it, but here are the
ideas I have. (All numbers are for context diff format.)
If I cut a patch right now for everything, it would be 7742 lines.
Right now a patch of the doc/ changes would be 413 lines.
If I split out the src/test/regress/ part it would be 1340 lines,
mostly python code for dtester tests.
If I split out just the src/bin/pg_dump/ changes it would be 98
lines.
Splitting out those three would leave src/backend/ and src/include/
which comes in at a svelte 5891 lines.
With a little more work I could split the three new files
(predicate.c, predicate.h, and predicate_internals.h) out from the
changes scattered around the rest of the code. That's 4346 lines and
1545 lines, respectively.
Now, these numbers are likely to change a little in the next few
days, but not much as a percentage outside the documentation.
Thoughts?
-Kevin
