Re: Alias collision in `refresh materialized view concurrently` - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Alias collision in `refresh materialized view concurrently`
Date
Msg-id YLWQNT0DiIskg5oq@paquier.xyz
Whole thread Raw
In response to Re: Alias collision in `refresh materialized view concurrently`  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Alias collision in `refresh materialized view concurrently`
List pgsql-hackers
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@paquier.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

Attachment

pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: CALL versus procedures with output-only arguments
Next
From: "David G. Johnston"
Date:
Subject: Re: CALL versus procedures with output-only arguments