Cluster Features and Commit order of transactions

I just applied many updates to the
http://wiki.postgresql.org/wiki/ClusterFeatures page:

-The description of "Function scan push-down" and "Modification trigger
into core" now reflect discussion here on the list last month
-Wrote initial descriptions based on my own understanding of the issues
for "DDL Triggers", "Dynamic shared memory allocation", "XID feed", and
"Creation of primary keys online"

Please directly correct those or let me know if there's anything I did
that that doesn't look right. We're almost done with getting this
document readable now.

The main still confusing entry there is "Commit order of transactions".
I can't really make out what the point of that is supposed to be. How
is it that these "commit in reverse order" situations pop up? I think
this one may have prematurely wandered too far into implementation
details too. The idea of having a lookup table to associate xid and
timestamp would be helpful in a number of cases (that has popped up as
useful for Hot Standby too). But I have my doubts about whether
scraping backwards in the WAL to get that data is ever going to be an
acceptable way to handle that.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us