pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: In pg_dump, don't dump a stats object unless dumping underlying 6+ messages / 1 participants [nested] [flat]
* pgsql: In pg_dump, don't dump a stats object unless dumping underlying @ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In pg_dump, don't dump a stats object unless dumping underlying table. If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/aa2e323eedc9e3cbad4eae19b309f92c8ba8afeb Modified Files -------------- src/bin/pg_dump/pg_dump.c | 30 +++++++++++++++++++++++++++--- src/bin/pg_dump/pg_dump.h | 1 + src/bin/pg_dump/t/002_pg_dump.pl | 6 +++--- 3 files changed, 31 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In pg_dump, don't dump a stats object unless dumping underlying @ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In pg_dump, don't dump a stats object unless dumping underlying table. If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/69d7edb06fc69da114b075be58dd4318916500e5 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 28 ++++++++++++++++++++++++++-- src/bin/pg_dump/pg_dump.h | 1 + src/bin/pg_dump/t/002_pg_dump.pl | 6 +++--- 3 files changed, 30 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In pg_dump, don't dump a stats object unless dumping underlying @ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In pg_dump, don't dump a stats object unless dumping underlying table. If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b2c9936a7156926ace70b89ffb9cfbe1e3b9a559 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 30 +++++++++++++++++++++++++++--- src/bin/pg_dump/pg_dump.h | 3 ++- src/bin/pg_dump/t/002_pg_dump.pl | 5 +++-- 3 files changed, 32 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In pg_dump, don't dump a stats object unless dumping underlying @ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In pg_dump, don't dump a stats object unless dumping underlying table. If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7418767f11d11ca4003ed3e8e96296eabb2acfe1 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 30 +++++++++++++++++++++++++++--- src/bin/pg_dump/pg_dump.h | 3 ++- src/bin/pg_dump/t/002_pg_dump.pl | 5 +++-- 3 files changed, 32 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In pg_dump, don't dump a stats object unless dumping underlying @ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In pg_dump, don't dump a stats object unless dumping underlying table. If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1e0841426e968f184277e7638227b16fb3cdca7a Modified Files -------------- src/bin/pg_dump/pg_dump.c | 30 +++++++++++++++++++++++++++--- src/bin/pg_dump/pg_dump.h | 3 ++- src/bin/pg_dump/t/002_pg_dump.pl | 6 +++--- 3 files changed, 32 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: In pg_dump, don't dump a stats object unless dumping underlying @ 2023-12-29 15:57 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-29 15:57 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org In pg_dump, don't dump a stats object unless dumping underlying table. If the underlying table isn't being dumped, it's useless to dump an extended statistics object; it'll just cause errors at restore. We have always applied similar policies to, say, indexes. (When and if we get cross-table stats objects, it might be profitable to think a little harder about what to do with them. But for now there seems no point in considering a stats object as anything but an appendage of its table.) Rian McGuire and Tom Lane, per report from Rian McGuire. Back-patch to supported branches. Discussion: https://postgr.es/m/7075d3aa-3f05-44a5-b68f-47dc6a8a0550@buildkite.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8d4e8b746815505c3b808ab96674ec2e140afc56 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 30 +++++++++++++++++++++++++++--- src/bin/pg_dump/pg_dump.h | 1 + src/bin/pg_dump/t/002_pg_dump.pl | 6 +++--- 3 files changed, 31 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-12-29 15:57 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us> 2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us> 2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us> 2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us> 2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us> 2023-12-29 15:57 pgsql: In pg_dump, don't dump a stats object unless dumping underlying Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox