Re: pg_restore handles extended statistics inconsistently with statistics data

> On Jun 12, 2026, at 14:05, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Thu, Jun 11, 2026 at 11:31:26AM +0800, Chao Li wrote:
>> I tried the same test against 1ea44d7ddfb, the immediate predecessor
>> of c32fb29e9. pg_dump dumped relation stats and attribute stats,
>> while pg_restore restored nothing. So the asymmetric behavior for
>> stats already existed. c32fb29e9 then added extended stats to both
>> pg_dump and pg_restore, but the new EXTENDED STATISTICS DATA entries
>> are handled differently from STATISTICS DATA during selective
>> pg_restore, making the inconsistency visible.
>> 
>> The asymmetric behavior was not introduced by c32fb29e9, so I think
>> we probably should not change that for v19. If it's confirmed that
>> this needs to be fixed and nobody else plans to work on it, I would
>> be happy to add it to my TODO list for v20.
> 
> FWIW, I'm going to disagree with your argument, as I find the behavior
> of v18 really weird.  

Yeah, I had the same feeling.

> I would have assumed that the pg_restore
> --statistics-only should restore all the stats in the schema without
> the objects in the schema, relation and attribute stats (+extended,
> only applies with v19), for all the objects in the schema.  If you
> want only the schema definition and not the objects, we already have
> -s for the job.
> 
> In your example, the dump in custom format with --statistics looks
> right to me: object definitions and stats.  pg_dump -Fc
> --statistics-only also looks right: only the stats, no objects.  The
> restore part is bumpy.
> 
> So I'd like to think that the behavior of the relation and attribute
> stats is wrong in v18 and v19, and that the behavior of extended stats
> is actually the right one in v19.  Why should custom and plain formats
> differ when filtering with a --schema and --statistics-only?
> 
> At the end, it seems to me that the right thing to do is the patch
> attached, to-be-backpatched down to v18.  

Totally agreed. Making pg_dump and pg_restore behave consistently also feels like the right direction to me.

I was just not sure if we should do that now or for v20, as we are supposed to fix v19-only issues at the current stage. I didn’t verify that on v18.

> check-world passes with this
> patch, so we have never tested really this path, I guess?  I could see
> myself adding a scenario in 003, at least.
> 
> Jeff or Corey, could you comment please?
> --
> Michael
> <0001-Fix-pg_restore-with-schema-and-statistics-only.patch>

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/