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 |
Date: | 2020-01-30 19:39:47 |
Message-ID: | 11160.1580413187@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
booby-trap-fork.patch | text/x-diff | 467 bytes |
0001-fix-worker-status.patch | text/x-diff | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
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 |