On Fri, Jan 20, 2012 at 9:44 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> I've taken that idea and used it to build a second Clog cache, known >>> as ClogHistory which allows access to the read-only tail of pages in >>> the clog. Once a page has been written to for the last time, it will >>> be accessed via the ClogHistory Slru in preference to the normal Clog >>> Slru. This separates historical accesses by readers from current write >>> access by committers. Historical access doesn't force dirty writes, >>> nor are commits made to wait when historical access occurs. >> >> This seems to need a rebase. > > OT: It would save lots of time if we had 2 things for the CF app: > > 1. Emails that go to appropriate people when status changes. e.g. when > someone sets "Waiting for Author" the author gets an email so they > know the reviewer is expecting something. No knowing that wastes lots > of days, so if we want to do this in less days that seems like a great > place to start. > > 2. Something that automatically tests patches. If you submit a patch > we run up a blank VM and run patch applies on all patches. As soon as > we get a fail, an email goes to patch author. That way authors know as > soon as a recent commit invalidates something. > > Those things have wasted time for me in the past, so they're > opportunities to improve the process, not must haves.
Yeah, I agree that that would be nice. I just haven't had time to implement much of anything for the CF application in a long time. My management has been very interested in the performance and scalability stuff, so that's been my main focus for 9.2. I'm going to see if I can carve out some time for this once the dust settles. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
