Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane <tgl@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