Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iL15E-0002Kt-3T for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Oct 2019 08:24:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iL15C-0001ZH-Pw for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Oct 2019 08:24:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iL12O-0007Ie-7P for pgsql-hackers@lists.postgresql.org; Thu, 17 Oct 2019 08:21:36 +0000 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iL12J-00058J-R4 for pgsql-hackers@lists.postgresql.org; Thu, 17 Oct 2019 08:21:33 +0000 Received: by mail-ed1-x544.google.com with SMTP id r4so1040426edy.4 for ; Thu, 17 Oct 2019 01:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ZvAEkbFSZVS7xk0RTQZQwvlw1TmGJhtXUOmIEJS8QmM=; b=ve3C0q7tK6BoG6BW5SV8fsFUGbEJFY7aJLASQ7n6rIE8JKg+Rh2dBlziDrK+sBIiJY ZfbvDd3iU4sPnpXvUZ9kIYO3bPXVwUoYcX7ftJT6cK8GoZxfbnSqBFrO25PFeVKD34uN SR1CzCPZIN1f+hpI+f3k1ljwocSMETprAD9+Jy5smmXvClnQCxnf0KJFY/LWLnI4/Dd4 010YYhmchB0SJlEXFR9TngQysnhlkXKTlSQ/4Hrh2n4YXPIB+B8cfTnqw1swD88DwgVX ZpEcs4PkGB0Sddoy4ZxZxVAWehYLpUdXaZ3f4W6GlHLOwgnbTlAXcQUh5lGmLdU5uN1G 8gWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ZvAEkbFSZVS7xk0RTQZQwvlw1TmGJhtXUOmIEJS8QmM=; b=OwdiaC0QiGKxpEpQ0iCvHofcb5xGpMOl5d5E/ilXRuuNqvyfHo/1m4J4Wwrw2ELaMA ML6EwLiC79sfyhzj6BW20lmCre2kQchPH7uak1i1pdHk+5E7jtsxBEHY6ra2yWTulZdL yHiA+WeP9RUXhEPVxcxnFQ2lDE9vG4xL5nX+GAErMsypkK9lrHokFvhHVnXfXeTdI2g/ KsrJSJfa1vCMgZfIk8HXxwCEYJCF0zRbWVvNq9puKm8WfN6wJSf06fQFHc14JRuK1nCK p+IDJVffGRZ66kXhLYd57aPTdM/MBvGCEkVQPgn23xg6mSYfsYzhr7XclrNW49GlkH/k f8xQ== X-Gm-Message-State: APjAAAV+Cnveesc76F58rFHVDZUW68nGmmGlbmsZWA953NZqSWXrhjXQ HJZ9UeLJrxaZPzWbyCc7vFtJDHIVhdxONn5c09fOkL9k2qo3ZSsrqI/285Avdw3QfyBrI9PeroX T5CsBZTWJ27+bfa188hsNTbEEN5PMIPuTpyewJD4ZRrfO+MWY61QDcQdZzP52de1pjwfBkbFNxc pNhv8DoR/0bMeTqcFG X-Google-Smtp-Source: APXvYqxK0k91HqZ8zfhG+oVGM+9z1O8ZV4a41AT8y3bjA3oCTLp07zwXLwXJ0i68UzA7Mry8F+BSbw== X-Received: by 2002:a05:6402:650:: with SMTP id u16mr2399413edx.211.1571300489968; Thu, 17 Oct 2019 01:21:29 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([82.102.24.174]) by smtp.gmail.com with ESMTPSA id l1sm71262edc.11.2019.10.17.01.21.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2019 01:21:29 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id B24D4300A24; Thu, 17 Oct 2019 05:14:25 -0300 (-03) Date: Thu, 17 Oct 2019 05:14:25 -0300 From: Alvaro Herrera To: Pg Hackers Subject: Re: parallel restore sometimes fails for FKs to partitioned tables Message-ID: <20191017081425.GA18878@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191005224333.GA9738@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Oct-05, Alvaro Herrera wrote: > While playing around I noticed that depending on the number of parallel > workers in pg_restore compared to the number of partitions a table has, > restoring an FK fails because the FK itself is restored before the index > partitions have completed restoring. The exact conditions to cause the > failure seem to vary depending on whether the dump is schema-only or not. > > This can seemingly be fixed by having pg_dump make the constraint depend > on the attach of each partition, as in the attached patch. With this > patch I no longer see failures. Pushed with some additional tweaks. Parallel restore of partitioned tables containing data and unique keys still fails with some deadlock errors, though :-( -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services