|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||vignesh C <vignesh21(at)gmail(dot)com>|
|Cc:||Ahsan Hadi <ahsan(dot)hadi(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: pg_restore crash when there is a failure before all child process is created|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
vignesh C <vignesh21(at)gmail(dot)com> writes:
> On Wed, Jan 29, 2020 at 6:54 PM Ahsan Hadi <ahsan(dot)hadi(at)gmail(dot)com> wrote:
>> Can you share a test case or steps that you are using to reproduce this issue? Are you reproducing this using a debugger?
> I could reproduce with the following steps:
> Make cluster setup.
> Create few tables.
> Take a dump in directory format using pg_dump.
> Restore the dump generated above using pg_restore with very high
> number for --jobs options around 600.
I agree this is quite broken. Another way to observe the crash is
to make the fork() call randomly fail, as per booby-trap-fork.patch
below (not intended for commit, obviously).
I don't especially like the proposed patch, though, as it introduces
a great deal of confusion into what ParallelState.numWorkers means.
I think it's better to leave that as being the allocated array size,
and instead clean up all the fuzzy thinking about whether workers
are actually running or not. Like 0001-fix-worker-status.patch below.
regards, tom lane
|Next Message||Peter Geoghegan||2020-01-30 19:40:24||Re: Enabling B-Tree deduplication by default|
|Previous Message||Peter Geoghegan||2020-01-30 19:16:34||Re: Enabling B-Tree deduplication by default|