Josh Berkus <josh@agliodbs.com> wrote:
>> That was deemed to be incompatible with unlogged matviews, which
>> some didn't want to give up in this initial release.
>
> Huh? Unlogged tables don't go in pg_class?
Sorry if I wasn't clear. I try to do incremental development --
get one part working and then go on to the next. I had stored the
"populated" state in pg_class, although under what, in retrospect,
was a bad name -- I had a bool called relisvalid. It should have
been relispopulated or a bit in a flag byte. Anyway, as I
proceeded to implement the unlogged feature I discovered that the
heap is truncated at recovery time based on the init fork, before
the server is at the point where we can access the system tables.
So then I tried to keep the pg_class state but populate it when an
unlogged matview was opened, based on using the "special" space in
the first page of the init fork, updating pg_class if that was
found to indicate a truncated heap. I was roundly criticized for
"keeping this state in two places" -- both the heap and pg_class,
and urged to keep it only in the heap, because only keeping it in
pg_class would not allow the proper recovery for an unlogged
matview. So I responded to that feedback with the current
implementation.
Clearly we would need to change how we do recovery of unlogged
relations to both allow unlogged matviews and keep the populated
state in pg_class. I don't think we can really make the "two
places" technique work, where the recovery state of the unlogged
matview is used to trigger a pg_class change. For one thing, it
was really messy -- far more so than current code. For another
thing, the matview would show as good until it was first opened,
which was nasty.
Kinda verbose, but I hope that makes it more clear.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
