On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I cannot say that I find that idea attractive; the biggest problem with
>>> it being that updating such a state flag will be nontransactional,
>>> unless we go to a lot of effort to support rollbacks. ISTM that the
>>> scannability property is a perfectly normal relation property and as
>>> such *ought* to be in the pg_class row, or at worst some other catalog
>>> entry. Why do you think differently?
>
>> Mostly because of the issue with unlogged tables, I suppose. If
>> you've got a reasonable idea how to do catalog updates on restart,
>> though, I could probably be convinced to yield to that.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company