Re: Alias collision in `refresh materialized view concurrently`

On Fri, May 21, 2021 at 03:56:31PM +0530, Bharath Rupireddy wrote:
> On Fri, May 21, 2021 at 6:08 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> 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.
>
> I agree that backend ID and/or PID is enough. I'm not fully convinced
> with using random(). To make it more concrete, how about something
> like pg.matview.%d.%d (MyBackendId, MyProcPid)? If the user still sees
> some collisions, then IMHO, it's better to ensure that this kind of
> table/alias names are not generated outside of the server.

There is no need to have the PID if MyBackendId is enough, so after
considering it I would just choose something like what I quoted above.
Don't we need also to worry about the queries using newdata, newdata2
and diff as aliases? Would you like to implement a patch doing
something like that?
--
Michael