Re: REFRESH MATERIALIZED VIEW locklevel

"anarazel(at)anarazel(dot)de" <andres(at)anarazel(dot)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