Re: pg_restore V12 fails consistently against piped pg_dumps - Mailing list pgsql-general

From Mohamed Wael Khobalatte
Subject Re: pg_restore V12 fails consistently against piped pg_dumps
Date
Msg-id CABZeWdwqqVBWR5Footjqg09T9MioWEKnh4a8gfitqrgQWSPSKA@mail.gmail.com
Whole thread Raw
In response to Re: pg_restore V12 fails consistently against piped pg_dumps  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
On Fri, May 8, 2020 at 10:59 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
> On 5/7/20 11:47 PM, Laurenz Albe wrote:
> > On Thu, 2020-05-07 at 11:04 -0400, Mohamed Wael Khobalatte wrote:
> >> Thanks Tom, I will review those changes tonight. In the meantime, to
> >> reproduce, I run the following:
> >>
> >> - createdb test
> >> - create some tables, I used a simple loop to create 10 empty ones.
> >> - pg_dump -v -Fc test | tee test.dump > /dev/null (so it's through a
> >> pipe, same as if the file is streamed through curl which was the
> >> original case)
> >> - pg_restore -j4 --verbose --clean --no-acl --no-owner -d test test.dump
> >>
> >> That should fail consistently. pg_restore_12 and pg_dump_12. Same
> >> passes in if I run in earlier versions.
> >
> > I just tried that and didn't encounter any errors.
>
> I did:
>
> pg_dump -d production -U postgres -Fc |tee test.dump > /dev/null
>
> pg_restore -j4 -d production_test -U postgres test.dump
>
> pg_restore: error: could not find block ID 4804 in archive -- possibly
> due to out-of-order restore request, which cannot be handled due to lack
> of data offsets in archive
> pg_restore: error: could not find block ID 4806 in archive -- possibly
> due to out-of-order restore request, which cannot be handled due to lack
> of data offsets in archive
> pg_restore: error: a worker process died unexpectedly
>
>
> Whereas a restore without -j4 succeeded.
>
> >
> > Please come up with a more complete example.
> >
> > Are you OS user "postgres" when you run that?
>
> >
> > Yours,
> > Laurenz Albe
> >
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com

Laurenz, I did the same as Adrian above, but with my own
non-"postgres" user. Between my check and Adrian's, it seems to be
user-indepedent (although I don't know what that would mean
precisely).



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: pg_basebackup cannot compress to STDOUNT
Next
From: Adrian Klaver
Date:
Subject: Re: Odd postgres12 upgrade is changing or munging a password?