Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> Kevin Grittner <kgrittn@ymail.com> wrote:
>>>>> What is a real problem or risk with using this mechanism
>>>>> until we engineer something better? What problems with
>>>>> converting to a later major release does anyone see?
>>>>
>>>> Well, it's a pg_upgrade hazard, if nothing else, isn't it?
>>>
>>> I don't think so. What do you see as a problem?
>>
>> pg_upgrade only handles changes in catalog state, not on-disk
>> representation. If the on-disk representation of an
>> non-scannable view might change in a future release, it's a
>> pg_upgrade hazard.
>
> Yes, pg_upgrade is never going to write to data pages as that
> would be slow and prevent the ability to roll back to the
> previous cluster on error.
The only person who has suggested anything which would require that
is Andres, who suggests adding a metadata page to the front of the
heap to store information on whether the matview is populated. I
think it is the direct opposite of what Tom is suggesting, and has
too many issues to be considered at this time.
Nobody has proposed how the technique currently used creates a
pg_upgrade hazard now or in some future release where we provide a
way for recovery to put the information into the catalog. I have
gone into more detail on this earlier on this thread.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
