> On Jun 12, 2026, at 14:56, Chao Li <[email protected]> wrote: > > > >> On Jun 12, 2026, at 14:05, Michael Paquier <[email protected]> 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> >
If the fix direction is to make pg_restore behave consistently with pg_dump, then I think Michael's change is correct. I tried to add a test for this. Without the fix, the test fails as below: ``` # +++ tap check in src/bin/pg_dump +++ t/002_pg_dump.pl .. 9710/? # Failed test 'statistics_only_dump_test_schema_restore: should dump relstats_on_unanalyzed_tables' # at t/002_pg_dump.pl line 5339. # '-- ``` See the attached v2 for details. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v2-0001-Fix-pg_restore-with-schema-and-statistics-only.patch
Description: Binary data
