agora inbox for pgsql-committers@postgresql.org  
help / color / mirror / Atom feed
pgsql: pg_restore: Use dependency-based matching for STATISTICS DATA
2+ messages / 1 participants
[nested] [flat]

* pgsql: pg_restore: Use dependency-based matching for STATISTICS DATA
@ 2026-06-16 06:58  Michael Paquier <michael@paquier.xyz>
  0 siblings, 0 replies; 2+ messages in thread

From: Michael Paquier @ 2026-06-16 06:58 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

pg_restore: Use dependency-based matching for STATISTICS DATA

The previous approach introduced by 0dd93de69e80 was weak in terms of
name matching, as an --index=foo could match with a table with the same
name but from a different schema, pulling in more data than necessary.

For example, imagine the following case:
CREATE SCHEMA s1;
CREATE SCHEMA s2;
CREATE TABLE s1.foo (id int);
INSERT INTO s1.foo SELECT generate_series(1,100);
ANALYZE s1.foo;
CREATE TABLE s2.bar (id int);
CREATE INDEX foo ON s2.bar(id);
INSERT INTO s2.bar SELECT generate_series(1,100);
ANALYZE s2.bar;

A targetted pg_restore --index=foo would grab the relation and attribute
stats of s1.foo on top of the index s2.foo, which is incorrect.  This
commit fixes this scenario by relying on a lookup of the dependencies of
a STATISTICS DATA TOC entry, checking if a TOC entry depends on an index
or another relkind before matching with the names of the objects wanted
for the restore.

Discussion: https://postgr.es/m/ajDBwpxs-otl585H@paquier.xyz
Backpatch-through: 18

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/ae39bd23c662584d2c342b38a7939a38ff058076

Modified Files
--------------
src/bin/pg_dump/pg_backup_archiver.c | 39 +++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* pgsql: pg_restore: Use dependency-based matching for STATISTICS DATA
@ 2026-06-16 06:58  Michael Paquier <michael@paquier.xyz>
  0 siblings, 0 replies; 2+ messages in thread

From: Michael Paquier @ 2026-06-16 06:58 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

pg_restore: Use dependency-based matching for STATISTICS DATA

The previous approach introduced by 0dd93de69e80 was weak in terms of
name matching, as an --index=foo could match with a table with the same
name but from a different schema, pulling in more data than necessary.

For example, imagine the following case:
CREATE SCHEMA s1;
CREATE SCHEMA s2;
CREATE TABLE s1.foo (id int);
INSERT INTO s1.foo SELECT generate_series(1,100);
ANALYZE s1.foo;
CREATE TABLE s2.bar (id int);
CREATE INDEX foo ON s2.bar(id);
INSERT INTO s2.bar SELECT generate_series(1,100);
ANALYZE s2.bar;

A targetted pg_restore --index=foo would grab the relation and attribute
stats of s1.foo on top of the index s2.foo, which is incorrect.  This
commit fixes this scenario by relying on a lookup of the dependencies of
a STATISTICS DATA TOC entry, checking if a TOC entry depends on an index
or another relkind before matching with the names of the objects wanted
for the restore.

Discussion: https://postgr.es/m/ajDBwpxs-otl585H@paquier.xyz
Backpatch-through: 18

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/477efef089c31f7d260c923d64a2a75cb3aa580a

Modified Files
--------------
src/bin/pg_dump/pg_backup_archiver.c | 39 +++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2026-06-16 06:58 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-16 06:58 pgsql: pg_restore: Use dependency-based matching for STATISTICS DATA Michael Paquier <michael@paquier.xyz>
2026-06-16 06:58 pgsql: pg_restore: Use dependency-based matching for STATISTICS DATA Michael Paquier <michael@paquier.xyz>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox