Re: Alias collision in `refresh materialized view concurrently`

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Alias collision in `refresh materialized view concurrently`
Дата
Msg-id YLWQNT0DiIskg5oq@paquier.xyz
обсуждение исходный текст
Ответ на Re: Alias collision in `refresh materialized view concurrently`  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: Alias collision in `refresh materialized view concurrently`  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments