Re: properly sizing attnums in pg_get_publication_tables - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: properly sizing attnums in pg_get_publication_tables
Date
Msg-id 20230113192626.GZ9837@telsasoft.com
Whole thread Raw
In response to properly sizing attnums in pg_get_publication_tables  (Ted Yu <yuzhihong@gmail.com>)
List pgsql-hackers
On Fri, Jan 13, 2023 at 07:37:29AM -0800, Ted Yu wrote:
> Hi,
> I was looking at commit b7ae03953690a1dee455ba3823cc8f71a72cbe1d .
> 
> In `pg_get_publication_tables`, attnums is allocated with size
> `desc->natts`. However, since some columns may be dropped, this size may be
> larger than necessary.
> When `nattnums > 0` is false, there is no need to allocate the `attnums`
> array. In the current formation, `attnums` should be freed in this scenario.
> 
> Please take a look at the patch which moves the allocation to inside the
> `if (nattnums > 0)` block.
> 
> Thanks

It doesn't seem worth the bother of changing it or adding 10 lines of
code, or keeping track of whether "attnums" is initialized or not.

After all, it wasn't worth pfree()ing the array (which seems to work as
intended).  The array can't be larger than ~3200 bytes, and I doubt
anybody is going to be excited about saving a couple bytes per dropped
column.

-- 
Justin



pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: Transaction timeout
Next
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?