Horton

Re: Alias collision in `refresh materialized view concurrently`

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Bernd Helmle <mailings@oopsware.de>, Mathis Rudolf <mathis.rudolf@credativ.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-05-21T00:38:24Z
Lists: pgsql-hackers 
On Thu, May 20, 2021 at 09:14:45PM +0530, Bharath Rupireddy wrote:
> On Thu, May 20, 2021 at 7:52 PM Bernd Helmle <mailings@oopsware.de> wrote:
>> "mv" looks like a very common alias (i use it all over the time when
>> testing or playing around with materialized views, so i'm wondering why
>>  i didn't see this issue already myself). So the risk here for such a
>>  collision looks very high. We can try to lower this risk by choosing an
>>  alias name, which is not so common. With a static alias however you get
>>  a static error condition, not something that fails here and then.
> 
> Another idea is to use random() function to generate required number
> of uint32 random values(refresh_by_match_merge might need 3 values to
> replace newdata, newdata2 and mv) and use the names like
> pg_temp_rmv_<<rand_no1>>,  pg_temp_rmv_<<rand_no2>> and so on. This
> would make the name unguessable. Note that we use this in
> choose_dsm_implementation, dsm_impl_posix.

I am not sure that I see the point of using a random() number here
while the backend ID, or just the PID, would easily provide enough
entropy for this internal alias.  I agree that "mv" is a bad choice
for this alias name.  One thing that comes in mind here is to use an
alias similar to what we do for dropped attributes, say 
........pg.matview.%d........ where %d is the PID.  This will very
unlikely cause conflicts.
--
Michael

Commits

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

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