| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: pg_restore handles extended statistics inconsistently with statistics data |
| Date: | 2026-06-16 06:59:29 |
| Message-ID: | ajD0UZJFeO68ox-C@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 16, 2026 at 02:36:21PM +0800, Chao Li wrote:
> I think the dependency-based matching is better, but what happens if
> the archive is created with --statistics-only? In that case, the
> statistics entries still have dependencies, but the referenced
> parent TOC entries are not present in the archive. See the attached
> test script. It creates the archive with --statistics-only, with the
> new patch, neither table nor index stats are restored:
I can see your argument in that HEAD can improve the detection in what
gets restored if the dumps only include the stats data, but I don't
really buy that this is a use case interesting to support: one can
also dump the data with the index definition and then filter back the
contents when restoring using --index. So at the end having a tighter
check at the restore is more appealing to me, because it leads to a
more predictible result, like in the scenario I have posted upthread
when a schema has the idea to include tables and indexes with the same
names (unlikely, okay, still). Or in short, don't do that.
For the case of upgrades one or the other does not really matter,
pg_upgrade treats all the objects in full.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-06-16 07:20:19 | Re: pg_restore handles extended statistics inconsistently with statistics data |
| Previous Message | Shlok Kyal | 2026-06-16 06:39:47 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |