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

From Bernd Helmle
Subject Re: Alias collision in `refresh materialized view concurrently`
Date
Msg-id 33c96c3674c1797eef27f70233068d167a834c41.camel@oopsware.de
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
Am Dienstag, dem 01.06.2021 um 13:13 +0530 schrieb Bharath Rupireddy:
> I used MyProcPid which seems more random than MyBackendId (which is
> just a number like 1,2,3...). Even with this, someone could argue
> that
> they can look at the backend PID, use it in the materialized view
> names just to trick the server. I'm not sure if anyone would want to
> do this.
> 
> 

A generated query likely uses just an incremented value derived from
somewhere and in my opinion 1,2,3 makes it more likely that you get a
chance for collisions if you managed to get the same alias prefix
somehow. So +1 with the MyProcPid...

> I used the existing function make_temptable_name_n to prepare the
> alias names. The advantage of this is that the code looks cleaner,
> but
> it leaks memory, 1KB string for each call of the function. This is
> also true with the existing usage of the function. Now, we will have
> 5
> make_temptable_name_n function calls leaking 5KB memory. And we also
> have quote_qualified_identifier leaking memory, 2 function calls,
> 2KB.
> So, in total, these two functions will leak 7KB of memory (with the
> patch).
> 
> Shall I pfree the memory for all the strings returned by the
> functions
> make_temptable_name_n and quote_qualified_identifier? The problem is
> that pfree isn't cheaper.
> Or shall we leave it as is so that the memory will be freed up by the
> context?
> 

afaics the memory context is deleted after execution immediately, so
i'd assume it's okay.



-- 
Thanks,
    Bernd





pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Decoding speculative insert with toast leaks memory
Next
From: Amit Langote
Date:
Subject: parent foreign tables and row marks