On Fri, May 8, 2020 at 10:59 AM Adrian Klaver 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
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
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.du
On Thu, May 7, 2020 at 2:35 AM Tom Lane wrote:
>
> Without a concrete example it's hard to say, but maybe the issue is that
> v12 is more aggressive about parallelizing restores --- see 548e50976.
Thanks Tom, I will review those changes tonight. In the meantime, to
reproduce, I run the following:
Mohamed Wael Khobalatte 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
Hi all,
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
