"anara...@anarazel.de" <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers