Make materialized views participate in predicate locking

Enterprise / PostgreSQL - Michael Paquier [paquier.xyz] - 1 December 2022 06:41 UTC

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

43351557d0 Make materialized views participate in predicate locking
src/backend/storage/lmgr/predicate.c | 5 +-
src/test/isolation/expected/matview-write-skew.out | 121 +++++++++++++++++++++
src/test/isolation/isolation_schedule | 1 +
src/test/isolation/specs/matview-write-skew.spec | 51 +++++++++
4 files changed, 175 insertions(+), 3 deletions(-)

Upstream: git.postgresql.org


  • Share