Re: properly sizing attnums in pg_get_publication_tables

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Ted Yu <yuzhihong(at)gmail(dot)com>
Cc: akapila(at)postgresql(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: properly sizing attnums in pg_get_publication_tables
Date: 2023-01-13 19:26:26
Message-ID: 20230113192626.GZ9837@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-13 19:55:47 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message Nikolay Samokhvalov 2023-01-13 19:00:32 Re: Transaction timeout