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
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 |