Обсуждение: What is the meaning of pg_restore output?
Hi PG community,
I have questions about pg_restore output. pg_restore: creating DEFAULT "public.id"
and aren't present when -j 1 (or without -j)
So main questions are:
1. What is the meaning of this phrases?
2. Are they documented somewhere?
3. Is it possible that output change from version to version?
Why I am asking?
I saw a script which does pg_restore and grep some of this phrases as SUCCESS indicator that pg_restore passed OK (+ something like grep -iv "error").
script doesn't use pg_restore exit code because, as I understood from the authors, in the past were situations that pg_restore returned 0 code but didn't restore of db.
Any answers, hints are welcome :).
Thanks
On 03/08/2018 01:49 AM, Alexandru Lazarev wrote: > Hi PG community, > I have questions about pg_restore output. > > At some point of time in pg_restore output was such phrase > "*/pg_restore: setting owner and privileges for <RELATION_NAME>/*", then > it disappeared, it seems, when upgraded from PG 9.6.2 to 9.6.6 > Other phrases "pg_restore: processing /*item */3615 DEFAULT id > pg_restore: creating DEFAULT "public.id <http://public.id>" > are observed if pg_restore is executed with flag -j N (where N > 1) > and aren't present when -j 1 (or without -j) > > So main questions are: > 1. What is the meaning of this phrases? > 2. Are they documented somewhere? > 3. Is it possible that output change from version to version? I do not see any change in the release notes: https://www.postgresql.org/docs/9.6/static/release.html I would look at what at client_min_messages (enum) in: https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html It would also helpful to see the complete pg_dump and pg_restore commands you are working with. > > Why I am asking? > I saw a script which does pg_restore and grep some of this phrases as > SUCCESS indicator that pg_restore passed OK (+ something like grep -iv > "error"). > script doesn't use pg_restore exit code because, as I understood from > the authors, in the past were situations that pg_restore returned 0 code > but didn't restore of db. > > Any answers, hints are welcome :). > Thanks > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- Adrian Klaver adrian.klaver@aklaver.com
client_min_messages GUC didn't change
Commands are: pg_dump --host 127.0.0.1 --port 5432 --username postgres --format custom --blobs --file /tmp/postgresql.backup -Z9 my_db
pg_restore -h 127.0.0.1 -p 5432 -U postgres -Fc -v -j$(nproc) -d my_db /tmp/postgresql.backup 2>&1 | tee /tmp/restore.txt
On Thu, Mar 8, 2018 at 5:30 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 03/08/2018 01:49 AM, Alexandru Lazarev wrote:Hi PG community,
I have questions about pg_restore output.
At some point of time in pg_restore output was such phrase "*/pg_restore: setting owner and privileges for <RELATION_NAME>/*", then it disappeared, it seems, when upgraded from PG 9.6.2 to 9.6.6
Other phrases "pg_restore: processing /*item */3615 DEFAULT id
pg_restore: creating DEFAULT "public.id <http://public.id>"
are observed if pg_restore is executed with flag -j N (where N > 1)
and aren't present when -j 1 (or without -j)
So main questions are:
1. What is the meaning of this phrases?
2. Are they documented somewhere?
3. Is it possible that output change from version to version?
I do not see any change in the release notes:
https://www.postgresql.org/docs/9.6/static/release.html
I would look at what at client_min_messages (enum) in:
https://www.postgresql.org/docs/9.6/static/runtime-config- logging.html
It would also helpful to see the complete pg_dump and pg_restore commands you are working with.
Why I am asking?
I saw a script which does pg_restore and grep some of this phrases as SUCCESS indicator that pg_restore passed OK (+ something like grep -iv "error").
script doesn't use pg_restore exit code because, as I understood from the authors, in the past were situations that pg_restore returned 0 code but didn't restore of db.
Any answers, hints are welcome :).
Thanks
<https://www.avast.com/sig-email?utm_medium=email&utm_source =link&utm_campaign=sig-email& utm_content=webmail&utm_term= icon> Virus-free. www.avast.com <https://www.avast.com/sig-ema il?utm_medium=email&utm_source =link&utm_campaign=sig-email& utm_content=webmail&utm_term= link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
Adrian Klaver
adrian.klaver@aklaver.com
On 03/08/2018 09:06 AM, Alexandru Lazarev wrote: > client_min_messages GUC didn't change > > Commands are: > pg_dump --host 127.0.0.1 --port 5432 --username postgres --format custom > --blobs --file /tmp/postgresql.backup -Z9 my_db > > pg_restore -h 127.0.0.1 -p 5432 -U postgres -Fc -v -j$(nproc) -d my_db > /tmp/postgresql.backup 2>&1 | tee /tmp/restore.txt > > When I restore using 10.2 I see: pg_restore: creating ACL "public.TABLE wl_week" Do you see something similar? My suspicion is that this might have something to do with the commits below: https://git.postgresql.org/gitweb/?p=postgresql.git&a=search&h=HEAD&st=commit&s=+ACL Someone with more knowledge of this will need to confirm or deny. -- Adrian Klaver adrian.klaver@aklaver.com
Adrian Klaver <adrian.klaver@aklaver.com> writes: > When I restore using 10.2 I see: > pg_restore: creating ACL "public.TABLE wl_week" > Do you see something similar? > My suspicion is that this might have something to do with the commits below: Yeah, this evidently changed in commits 3eb9a5e7c et al, which made ACL restore go through restore_toc_entry(). I think I figured that the "creating ACL" message that restore_toc_entry() would emit made the dedicated "setting owner and privileges" message redundant. It had also been misleading for quite some time, maybe forever: restore of that TOC entry would set the object's privileges all right, but if it ever had anything to do with setting the object's ownership, it was a really long time ago. regards, tom lane
Hi All, Thanks for your replies.
What about "item" key-word - is it appearing only when -j > 1?are observed if pg_restore is executed with flag -j N (where N > 1)
and aren't present when -j 1 (or without -j)
2. Are they (output phrases) documented somewhere?
On Thu, Mar 8, 2018 at 11:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> When I restore using 10.2 I see:
> pg_restore: creating ACL "public.TABLE wl_week"
> Do you see something similar?
> My suspicion is that this might have something to do with the commits below:
Yeah, this evidently changed in commits 3eb9a5e7c et al, which made ACL
restore go through restore_toc_entry(). I think I figured that the
"creating ACL" message that restore_toc_entry() would emit made the
dedicated "setting owner and privileges" message redundant. It had also
been misleading for quite some time, maybe forever: restore of that TOC
entry would set the object's privileges all right, but if it ever had
anything to do with setting the object's ownership, it was a really long
time ago.
regards, tom lane
On 03/17/2018 07:30 AM, Alexandru Lazarev wrote: > Hi All, Thanks for your replies. > What about "item" key-word - is it appearing only when -j > 1? > > Other phrases "pg_restore: processing /*item */3615 DEFAULT id > pg_restore: creating DEFAULT "public.id <http://public.id>" > are observed if pg_restore is executed with flag -j N (where N > 1) > and aren't present when -j 1 (or without -j) > > > 2. Are they (output phrases) documented somewhere? Grepping source in src/bin/pg_dump/: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/pg_dump/pg_backup_archiver.c;h=8892b177905ea81b58ddbc728fd46d47e2d017c6;hb=65c6b53991e1c56f6a0700ae26928962ddf2b9fe if (do_now) { /* OK, restore the item and update its dependencies */ ahlog(AH, 1, "processing item %d %s %s\n", next_work_item->dumpId, next_work_item->desc, next_work_item->tag); Which is in section with this comment: /* * Main engine for parallel restore. * * Parallel restore is done in three phases. In this first phase, * we'll process all SECTION_PRE_DATA TOC entries that are allowed to be * processed in the RESTORE_PASS_MAIN pass. (In practice, that's all * PRE_DATA items other than ACLs.) Entries we can't process now are * added to the pending_list for later phases to deal with. */ -- Adrian Klaver adrian.klaver@aklaver.com