Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Ensure that "pg_restore -l" reports dependent TOC entries correctly.

  1. pg_restore -N loses extension comment

    Justin Pryzby <pryzby@telsasoft.com> — 2024-05-07T12:28:58Z

    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

  2. Re: pg_restore -N loses extension comment

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-05-07T13:52:49Z

    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

  3. Re: pg_restore -N loses extension comment

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-05-07T14:49:29Z

    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