| 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: | Whole Thread | Raw Message | 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 |