Re: pg_restore V12 fails consistently against piped pg_dumps

From: Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: pg_restore V12 fails consistently against piped pg_dumps
Date: 2020-05-08 19:21:45
Message-ID: CABZeWdwqqVBWR5Footjqg09T9MioWEKnh4a8gfitqrgQWSPSKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 8, 2020 at 10:59 AM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)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).

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2020-05-08 19:23:21 Re: Odd postgres12 upgrade is changing or munging a password?
Previous Message Adrian Klaver 2020-05-08 19:18:59 Re: pg_basebackup cannot compress to STDOUNT