pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_restore -N loses extension comment
3+ messages / 2 participants
[nested] [flat]
* pg_restore -N loses extension comment
@ 2024-05-07 12:28 Justin Pryzby <pryzby@telsasoft.com>
0 siblings, 1 reply; 3+ messages in thread
From: Justin Pryzby @ 2024-05-07 12:28 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
pg_dump -Fc |pg_restore -l -N schema:
| 2; 3079 18187 EXTENSION - pg_buffercache
Without -N schema also shows:
| 2562; 0 0 COMMENT - EXTENSION pg_buffercache
I mean literal s-c-h-e-m-a, but I suppose anything else will work the
same.
BTW, I noticed that pg_restore -v shows that duplicate dependencies can be
stored. We see things like this (and worse).
| 4284; 1259 191439414 VIEW public wmg_server_view telsasoft
| ; depends on: 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 612 23087 612
I see that's possible not only for views, but also tables.
That's probaably wasteful of CPU, at least.
--
Justin
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pg_restore -N loses extension comment
@ 2024-05-07 13:52 Tom Lane <tgl@sss.pgh.pa.us>
parent: Justin Pryzby <pryzby@telsasoft.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2024-05-07 13:52 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: pgsql-hackers@lists.postgresql.org
Justin Pryzby <pryzby@telsasoft.com> writes:
> pg_dump -Fc |pg_restore -l -N schema:
> | 2; 3079 18187 EXTENSION - pg_buffercache
> Without -N schema also shows:
> | 2562; 0 0 COMMENT - EXTENSION pg_buffercache
Hmm, but what happens if you actually do the restore?
I think this may be a bug in -l mode: ProcessArchiveRestoreOptions
saves the result of _tocEntryRequired in te->reqs, but PrintTOCSummary
doesn't, and that will bollix its subsequent _tocEntryRequired checks
for "dependent" TOC entries.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pg_restore -N loses extension comment
@ 2024-05-07 14:49 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2024-05-07 14:49 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: pgsql-hackers@lists.postgresql.org
I wrote:
> I think this may be a bug in -l mode: ProcessArchiveRestoreOptions
> saves the result of _tocEntryRequired in te->reqs, but PrintTOCSummary
> doesn't, and that will bollix its subsequent _tocEntryRequired checks
> for "dependent" TOC entries.
Yeah ... the attached seems to fix it.
regards, tom lane
Attachments:
[text/x-diff] fix-selective-l-mode.patch (796B, ../../4110200.1715093369@sss.pgh.pa.us/2-fix-selective-l-mode.patch)
download | inline diff:
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index c6c101c118..56e0688154 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -1319,10 +1319,13 @@ PrintTOCSummary(Archive *AHX)
curSection = SECTION_PRE_DATA;
for (te = AH->toc->next; te != AH->toc; te = te->next)
{
+ /* This bit must match ProcessArchiveRestoreOptions' marking logic */
if (te->section != SECTION_NONE)
curSection = te->section;
+ te->reqs = _tocEntryRequired(te, curSection, AH);
+ /* Now, should we print it? */
if (ropt->verbose ||
- (_tocEntryRequired(te, curSection, AH) & (REQ_SCHEMA | REQ_DATA)) != 0)
+ (te->reqs & (REQ_SCHEMA | REQ_DATA)) != 0)
{
char *sanitized_name;
char *sanitized_schema;
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-05-07 14:49 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-05-07 12:28 pg_restore -N loses extension comment Justin Pryzby <pryzby@telsasoft.com>
2024-05-07 13:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-05-07 14:49 ` 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