Robert Haas <robertmh...@gmail.com> writes: > On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Well, it's fairly clear *how* to do it: add some more processing that >> occurs after we've completed crash replay. We already have some of >> that, eg completion of partial splits in btrees, so it's not that much >> of a stretch; it's just a lot of code that's not been written yet.
> As far as I can see, that would require starting a separate backend > process for every database, and keeping track of which of those > completed their post-recovery work, and disallowing connections to any > given database until the post-recovery work for that database had been > completed. That seems to add quite a few failure modes that we don't > have today, which is why I haven't been much interested in going that > route. Well, I didn't say it would be easy or quick ;-). But you're presuming quite a number of design elements that don't seem essential to me. What I'd be inclined to think about as prerequisite work is fixing things so that a process could reattach to a new database, after flushing all its caches. That's a feature that's been requested plenty, and could have applications in autovacuum or other places besides this, and would certainly get lots of testing outside of crash recovery. Having done that, we could imagine that the startup process itself cycles through all the databases and does the fixup work, rather than complicating the postmaster logic as suggested above. Potentially this could replace the filesystem-scan-driven fixup logic that exists in it now, if it turns out to be faster to search for unlogged tables via a catalog scan rather than directory scans. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers