| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org, jkatz(at)postgresql(dot)org, nathandbossart(at)gmail(dot)com |
| Subject: | Re: Import Statistics in postgres_fdw before resorting to sampling. |
| Date: | 2026-04-12 18:15:00 |
| Message-ID: | 342868.1776017700@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> writes:
> Pushed. I closed the CF entry as well.
Coverity doesn't like this patch's uses of strncpy():
>>> CID 1691464: (BUFFER_SIZE)
>>> Calling "strncpy" with a maximum size argument of 64 bytes on destination array "remattrmap[attrcnt].local_attname" of size 64 bytes might leave the destination string unterminated.
5960 strncpy(remattrmap[attrcnt].local_attname, attname, NAMEDATALEN);
5961 strncpy(remattrmap[attrcnt].remote_attname, remote_attname, NAMEDATALEN);
I think it's dead right to complain: remote_attname, in particular,
could certainly be longer than NAMEDATALEN.
AFAICS, postgres_fdw's subsequent uses of those strings only need
them to be nul-terminated C strings, so strncpy's property of
zero-filling the whole buffer is not needed here. I recommend
s/strncpy/strlcpy/.
It's probably also appropriate to think about using pg_mbcliplen()
to ensure that this code doesn't result in a broken multibyte
character.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-04-12 18:20:31 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Previous Message | Tom Lane | 2026-04-12 18:05:02 | Re: Reduce build times of pg_trgm GIN indexes |