Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fbXhl-0007hw-7i for pgsql-admin@arkaria.postgresql.org; Fri, 06 Jul 2018 20:51:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fbXhi-0006g4-1w for pgsql-admin@arkaria.postgresql.org; Fri, 06 Jul 2018 20:51:46 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fbXhh-0006fx-Nl for pgsql-admin@lists.postgresql.org; Fri, 06 Jul 2018 20:51:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fbXhf-0005Qs-Bi for pgsql-admin@postgresql.org; Fri, 06 Jul 2018 20:51:44 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w66KpeoH026491; Fri, 6 Jul 2018 16:51:40 -0400 From: Tom Lane To: pavna cc: pgsql-admin@postgresql.org Subject: Re: pg_restore error Command was: CREATE OPERATOR ~> ( PROCEDURE = plv8x.json_eval_ls, In-reply-to: <1530896890067-0.post@n3.nabble.com> References: <1530850361998-0.post@n3.nabble.com> <69178.1530894011@sss.pgh.pa.us> <1530896890067-0.post@n3.nabble.com> Comments: In-reply-to pavna message dated "Fri, 06 Jul 2018 10:08:10 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <69652.1530910299.1@sss.pgh.pa.us> Date: Fri, 06 Jul 2018 16:51:39 -0400 Message-ID: <69653.1530910299@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk pavna writes: > Thanks Tom for your response! Is there a way to examine the backup to find > what was missing? Well, it's whatever was the commutator for that operator. Evidently it got dropped somewhere along the way. It's a bit curious that you have this situation, though. AFAICS, dropping an operator should result in clearing the oprcom link from its commutator sibling. Perhaps there's some sequence of operations that that logic fails to handle? It'd be interesting if you can show a way to reproduce this case. regards, tom lane