Re: REFRESH MATERIALIZED VIEW locklevel - Mailing list pgsql-hackers

From anarazel@anarazel.de
Subject Re: REFRESH MATERIALIZED VIEW locklevel
Date
Msg-id 5af0c8bd-4b0c-41d0-8442-70372818a749@email.android.com
Whole thread Raw
In response to Re: REFRESH MATERIALIZED VIEW locklevel  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: REFRESH MATERIALIZED VIEW locklevel
List pgsql-hackers

Kevin Grittner <kgrittn@ymail.com> schrieb:

>Andres Freund <andres@2ndquadrant.com> wrote:
>
>> if I understand things correctly REFRESH MATERIALIZED VIEW locks
>> the materialized view with an AcessExclusiveLock even if the view
>> already contains data.
>
>Yeah.  At the time I had to make a decision on that, REINDEX
>CONCURRENTLY did not seem reliable with a weaker lock, and REFRESH
>MATERIALIZED VIEW has to rebuild indexes (among other things).  If
>we have all the issues sorted out with REINDEX CONCURRENTLY then
>the same techniques will probably apply to RMV without too much
>difficulty.  It's a bit late to think about that for 9.3, though.
>
>> I am pretty sure that will - understandably - confuse users, so I
>> vote for at least including a note about that in the docs.
>
>Will see about working that in.

In the ride home I realized that unless - not that unlikely - you thought about something I didtn't  REFRESH will
behavesimilar to TRUNCATE for repeatable read+ transactions that only access it after REFRESH finished. That is, they
willappear empty. If that's the case, it needs to be documented prominently as well. 

It would be possible to get different behaviour by immediately freezing all tuples, but that would also result in
violationsof visibility by showing  tuples that are not yet visible. 

Andres

---
Please excuse brevity and formatting - I am writing this on my mobile phone.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: REFRESH MATERIALIZED VIEW locklevel
Next
From: "David E. Wheeler"
Date:
Subject: Duplicate JSON Object Keys