From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_restore V12 fails consistently against piped pg_dumps |
Date: | 2020-05-07 06:35:06 |
Message-ID: | 4717.1588833306@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com> writes:
> When doing a parallel pg_restore (v12) against a dump created through a
> pipe using an earlier version (11 all the way to 9.6), it fails with the
> known error of not finding data offsets. I understand the reasons for it
> (potential inability to seek), which is documented in pg_restore.
> What I don't understand is why the same `pg_restore -j` worked in earlier
> versions (say running pg_restore_v11 against the same dumps). Has anything
> changed in terms of ordering? I am actually quite curious what led to this
> finally breaking consistently.
Without a concrete example it's hard to say, but maybe the issue is that
v12 is more aggressive about parallelizing restores --- see 548e50976.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lisandro Rostagno | 2020-05-07 09:14:31 | Could not launch new process for connection: Could not allocate memory |
Previous Message | Mohamed Wael Khobalatte | 2020-05-07 04:35:48 | pg_restore V12 fails consistently against piped pg_dumps |