"anarazel@anarazel.de" <andres@anarazel.de> wrote:
> In the ride home I realized that unless - not that unlikely - you
> thought about something I didtn't REFRESH will behave similar to
> TRUNCATE for repeatable read+ transactions that only access it
> after REFRESH finished. That is, they will appear empty.
In an early version of the patch someone found that in testing and
pointed it out.
> It would be possible to get different behaviour by immediately
> freezing all tuples
Which is what I did.
> but that would also result in violations of visibility by showing
> tuples that are not yet visible.
Which is the case, and should be documented. (I had not remembered
to do so yet; I'll tuck away your email as a reminder.) Since the
MV is already not guaranteed to be in sync with other data, that
didn't seem like a fatal flaw. It is, however, the one case where
the MV could appear to be *ahead* of the supporting data rather
than *behind* it. In a way this is similar to how READ COMMITTED
transactions can see data from more than one snapshot on write
conflicts, so I see it as a bigger issue for more strict isolation
levels -- but those are unlikely to be all that useful with MVs in
this release anyway. This is something that I think deserves some
work in a subsequent release.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
