Horton

Alias collision in `refresh materialized view concurrently`

Mathis Rudolf <mathis.rudolf@credativ.de>

View thread View on postgr.es
From: Mathis Rudolf <mathis.rudolf@credativ.de>
To: pgsql-hackers@postgresql.org
Date: 2021-05-19T12:03:01Z
Lists: pgsql-hackers

Attachments

Hello,

we had a Customer-Report in which `refresh materialized view 
CONCURRENTLY` failed with: `ERROR: column reference "mv" is ambiguous`

They're using `mv` as an alias for one column and this is causing a 
collision with an internal alias. They also made it reproducible like this:
```
create materialized view testmv as select 'asdas' mv; --ok
create unique index on testmv (mv); --ok
refresh materialized view testmv; --ok
refresh materialized view CONCURRENTLY testmv; ---BAM!
```

```
ERROR: column reference "mv" is ambiguous
LINE 1: ...alog.=) mv.mv AND newdata OPERATOR(pg_catalog.*=) mv) WHERE ...
                                                               ^
QUERY:  CREATE TEMP TABLE pg_temp_4.pg_temp_218322_2 AS SELECT mv.ctid 
AS tid, newdata FROM public.testmv mv FULL JOIN pg_temp_4.pg_temp_218322 
newdata ON (newdata.mv OPERATOR(pg_catalog.=) mv.mv AND newdata 
OPERATOR(pg_catalog.*=) mv) WHERE newdata IS NULL OR mv IS NULL ORDER BY tid
```

The corresponding Code is in `matview.c` in function 
`refresh_by_match_merge`. With adding a prefix like `_pg_internal_` we 
could make collisions pretty unlikely, without intrusive changes.

The appended patch does this change for the aliases `mv`, `newdata` and 
`newdata2`.

Kind regards,
Mathis

Commits

  1. Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.

  2. Reduce risks of conflicts in internal queries of REFRESH MATVIEW CONCURRENTLY