diff options
| author | Michael Paquier <michael@paquier.xyz> | 2022-12-01 15:41:13 +0900 |
|---|---|---|
| committer | Michael Paquier <michael@paquier.xyz> | 2022-12-01 15:41:13 +0900 |
| commit | 43351557d0d2b9c5e20298b5fee2849abef86aff (patch) | |
| tree | df8f05365c1c3f8146bdfcc8022d61a84cbfb3ad /src/backend/executor/execParallel.c | |
| parent | d5515ca7cf1b095fab65c93710c71fece5baf67e (diff) | |
| download | postgresql-43351557d0d2b9c5e20298b5fee2849abef86aff.tar.gz postgresql-43351557d0d2b9c5e20298b5fee2849abef86aff.zip | |
Make materialized views participate in predicate locking
Matviews have been discarded from needing predicate locks since 3bf3ab8
and their introduction. At this point, there was no concurrent flavor
of REFRESH yet, hence there was no meaning in having materialized views
look at read/write conflicts with concurrent transactions using
themselves the serializable isolation level because they could only be
refreshed with an access exclusive lock. CONCURRENTLY, on the contrary,
allows reads and writes during a refresh as it holds a share update
exclusive lock.
Some isolation tests are added to show the effect of the change, with a
combination of one table and a matview based on it, using a mix of
REFRESH CONCURRENTLY and read/write queries.
This could arguably be considered as a bug, but as it is a subtle
behavior change potentially impacting applications no backpatch is
done.
Author: Yugo Nagata
Reviewed-by: Richard Guo, Dilip Kumar, Michael Paquier
Discussion: https://postgr.es/m/20220726164434.42d4e33911b4b4fcf751c4e7@sraoss.co.jp
Diffstat (limited to 'src/backend/executor/execParallel.c')
0 files changed, 0 insertions, 0 deletions