Re: Import Statistics in postgres_fdw before resorting to sampling.
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org,
jkatz@postgresql.org, nathandbossart@gmail.com
Date: 2026-04-30T18:04:22Z
Lists: pgsql-hackers
Attachments
- v1-0001-Replace-strncpy-with-pg_mbcliplen-plus-memcpy.patch (text/x-patch) patch v1-0001
- v1-0001-Replace-name-buffers-from-RemoteAttributeMapping-.patch (text/x-patch) patch v1-0001
> > > 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/. > > Seems like a good idea. > > > It's probably also appropriate to think about using pg_mbcliplen() > > to ensure that this code doesn't result in a broken multibyte > > character. > > Will do. > > I am currently overseas and will be attending an event this week, so I > will work on this after returning home. In the meantime, I created an > entry for it in the open items list. > > Thanks! I've attached 2 different fixes. The first one swtiches to pg_mbcliplen+memcpy, which is probably overkill but better safe than sorry. The second gets rid of the string buffers entirely, and instead frees the nested object. I have no preference between the two, though I suspect that the nested-free solution will be preferred by the community.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
postgres_fdw: Replace buffers in RemoteAttributeMapping with pointers.
- aa1f93a3387a 19 (unreleased) landed
-
Add support for importing statistics from remote servers.
- 28972b6fc3dc 19 (unreleased) landed