Re: Import Statistics in postgres_fdw before resorting to sampling. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Import Statistics in postgres_fdw before resorting to sampling.
Date
Msg-id 342868.1776017700@sss.pgh.pa.us
Whole thread Raw
In response to Re: Import Statistics in postgres_fdw before resorting to sampling.  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Responses Re: Import Statistics in postgres_fdw before resorting to sampling.
List pgsql-hackers
Etsuro Fujita <etsuro.fujita@gmail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reduce build times of pg_trgm GIN indexes
Next
From: Tom Lane
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?