Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ju0Do-0004jD-IB for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 21:06:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ju0Dn-0002Cj-7G for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 21:06:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ju0Dm-0002Cb-Sy for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2020 21:06:15 +0000 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ju0Dj-00070u-K0 for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2020 21:06:14 +0000 Received: by mail-io1-xd31.google.com with SMTP id o5so7404501iow.8 for ; Fri, 10 Jul 2020 14:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6QDLy71WQbu8tmmNVL85epQgTvrQTGfhEnhLKhohwhs=; b=ieKQeoZ12oTb0usT6xALC97p9xatX3CeXb0+bX9y6Z8jZDPL2A01Xu5A+jn0p97EE9 jNMuMPj3PnzSoKH99t+g/1SC+bUTgBHIZsN5kLGr/1St5dsem5IcGehLRv1Ws41Ngb32 XvGILyAPti5BDAB/4aEl7mX1MmFLj9t/6Eo0uEhRATFV5fg2o2lgWo5oM0emCvv2ccme Xdk/pn1zrti/f+PzVPsQBzeAy9cRTtf+bMOClLUFAZRxJRXtPLhJfFEVjXdRYWWL/0rc YTaHrtUxw5lXHgJV1pBD+f+A+WOzY5YHeSeccaNc6ADPgFuuAa76tMvjyPb9VgIc3M4s 2DnA== 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:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6QDLy71WQbu8tmmNVL85epQgTvrQTGfhEnhLKhohwhs=; b=sSZNrRY+4tDPFe9MgMJQPpixF9Z6P4RWw6SejRlHyi7vC0zw4kObYeT7RwUmZ6xUiN 6XRPFxsi2C+IUp+fD6y/mhClupl48v2hZUurXyJWqv9VAkDDN4gdF1/PIgDsufhhylKQ Sl2cxq0ioTJyUgHnAMtJWTyd8RETua12AKo/yRCVgTyXAcYIzrmFosvHqeQa8kcz0RaH hqa90IVVMIaeJSGCPBTuZl0JwuwqhxOTGbAqKpMdTDP38cD4o6HVNfsi87g/o2DNyB7V Ar35TZQm3QwAlH0ZAGXsa4J4hxVHQXWj4Cs6bTAKzUjC+dBpisF1P+xFf7cn1cjJtPzA WoCA== X-Gm-Message-State: AOAM531EKSdMFLLV3lZRqeJVeOTRRQI0I6yGflkaTBo2QS6lWROgZwtH DPmY8XElRSQgHYWlZoR5NtB9ig== X-Google-Smtp-Source: ABdhPJwz+HnJhYaLHqt4bj0SHVtVoz3U/lLw2YCVw6vp7dmLZ6hXsXYpw8gjsxswtIglZ6zOPV8HMw== X-Received: by 2002:a5e:9b0e:: with SMTP id j14mr49996301iok.169.1594415169736; Fri, 10 Jul 2020 14:06:09 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k14sm4188063ion.17.2020.07.10.14.06.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 14:06:08 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id D2B66800C6F; Fri, 10 Jul 2020 16:06:07 -0500 (CDT) Date: Fri, 10 Jul 2020 16:06:07 -0500 From: Justin Pryzby To: Tom Lane Cc: David Gilman , pgsql-hackers@lists.postgresql.org Subject: Re: "tuple concurrently updated" in pg_restore --jobs Message-ID: <20200710210607.GR26220@telsasoft.com> References: <20200706050129.GW4107@telsasoft.com> <2116463.1594414480@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2116463.1594414480@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Jul 10, 2020 at 04:54:40PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > I hit this issue intermittently (roughly half the time) while working with a > > patch David submitted, and finally found a recipe to reproduce it on an > > unpatched v12 instance. > > > I was surprised to see pg_restore -j2 is restoring ACLs in pre-data in > > parallel. > > It's not pre-data. But it's true that pg_restore figures it can restore > ACLs in parallel during the ACL-restoring pass, on the theory that pg_dump > will not emit two different ACL entries for the same object, so that we > can do all the catalog updates in parallel without conflicts. > > This works about 99% of the time, in fact. It falls down in the --clean Note that this fails for me (sometimes) even without --clean. $ pg_restore pg_dump.out -j2 -d pryzbyj -v --section pre-data pg_restore: entering main parallel loop pg_restore: launching item 3395 ACL TABLE pg_proc pg_restore: launching item 3396 ACL COLUMN pg_proc.proname pg_restore: creating ACL "pg_catalog.TABLE pg_proc" pg_restore: creating ACL "pg_catalog.COLUMN pg_proc.proname" pg_restore: finished item 3395 ACL TABLE pg_proc pg_restore: launching item 3397 ACL COLUMN pg_proc.pronamespace pg_restore: creating ACL "pg_catalog.COLUMN pg_proc.pronamespace" pg_restore: while PROCESSING TOC: pg_restore: from TOC entry 3396; 0 0 ACL COLUMN pg_proc.proname postgres pg_restore: error: could not execute query: ERROR: tuple concurrently updated Command was: GRANT SELECT(proname) ON TABLE pg_catalog.pg_proc TO PUBLIC; -- Justin