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 1iCJ32-000192-5Y for pgsql-admin@arkaria.postgresql.org; Mon, 23 Sep 2019 07:46:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iCJ30-0000R1-MR for pgsql-admin@arkaria.postgresql.org; Mon, 23 Sep 2019 07:46:14 +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 1iCJ30-0000Oh-5v for pgsql-admin@lists.postgresql.org; Mon, 23 Sep 2019 07:46:14 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iCJ2B-0007XM-NM for pgsql-admin@lists.postgresql.org; Mon, 23 Sep 2019 07:46:10 +0000 Received: by mail-wm1-x341.google.com with SMTP id 5so8661051wmg.0 for ; Mon, 23 Sep 2019 00:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zunibal-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=bPIp9PI4XlrPuZCQT4nOjsHykwx5zKGCuT6XYcniStg=; b=w+tZn47TDLKBroVLqPEr4uHcTYpZ2gKL7XBA3D6/vIYOWOlg5eCycnOchMpzbk7nsh M/u7VjnLQoDeYip5pTPXpWI9+MzmhDSgbiA+ppl0LkNZ+0LGPZ/FPoLAvj8+y/TF7stc ZR8d8e/cTRY0Z26JlTWHxY6N04WbYCTxvMzwxUYfdHny3By8SMnkNIncxux6FURK2YU2 pPdEnhdCUyVZ8UXLx6FhGGUuCMBuhKscNjTxjbC4e3NgHvsX3Ld4gMTE+and1ZmQvblN rR901wfAVCFdt79nDn5/3tur8afMdr4a2gKTKpd+r65dqS6AZd0vznlefQKvCDj1BRK3 30tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bPIp9PI4XlrPuZCQT4nOjsHykwx5zKGCuT6XYcniStg=; b=fFOyUAgsFuTk+ebrh8ugpFBAl2r9zuAwjiHvFbIOJR6mNyo8cVgLdAvDu0H0QPweFU HrE0h9T7xgK00WxjaeYP+SuUbGc+zCTPffxUFL0Ywz+XXreRw8tV9M3mRr9YwtHIwDp1 NH7J+2IRhlw+L9jx05z2uU8Wu40M7bT8d2C2w1gQJEapZDWGDcnG4SBFO64dNgTMSrNz 6gPNo1M+7SJ+wxoEq4MbL+xP4qG85yVt2kRIVx6HcuWfVA3pbjHAfn4hw6AMbVI6a9us UtGlFTe3mNBrTXJADmkFuyF/KUMoIWIIwJq81HIGcDatcCnWDLvmWicaun08QWYRcAcd aedw== X-Gm-Message-State: APjAAAULqS736oK+aBAwS2uf6nf7lEPcCq8kbfgDGs7cnf2CV+4qp6mA hdklJRrP1dbDy1vYvGwN6davvV2tXX4= X-Google-Smtp-Source: APXvYqzg6VwzsRncpTSKLv2jnsZosNRrIqq7llHh/e6n1KGRQ681lMJtzt7RLSh9lQ82zzTWVE13rg== X-Received: by 2002:a05:600c:141:: with SMTP id w1mr12596053wmm.75.1569224715712; Mon, 23 Sep 2019 00:45:15 -0700 (PDT) Received: from [192.168.3.150] ([176.222.91.85]) by smtp.gmail.com with ESMTPSA id n8sm14230431wma.7.2019.09.23.00.45.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Sep 2019 00:45:15 -0700 (PDT) Subject: Re: Pg_upgrade error could not load library from 7.14/8.4 to 10.10 version To: pgsql-admin@lists.postgresql.org References: <4519fdad-d747-cd39-f6a2-33e7db1f3324@matrix.gatewaynet.com> <22046.1568901429@sss.pgh.pa.us> <13f3ecf4-248e-eb80-3906-fd2defe8a443@matrix.gatewaynet.com> From: Ekaterina Amez Message-ID: Date: Mon, 23 Sep 2019 09:45:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <13f3ecf4-248e-eb80-3906-fd2defe8a443@matrix.gatewaynet.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi Achilleas, El 20/9/19 a las 11:41, Achilleas Mantzios escribió: > On 20/9/19 12:22 μ.μ., Ekaterina Amez wrote: >> Hi Achilleas, >> >> After restoring backup in v8.4: >> >> newdb=# select proname,probin,pronamespace from pg_proc where >> proname='plpgsql_call_handler'; >>        proname        |                 probin                 | >> pronamespace >> ----------------------+----------------------------------------+-------------- >> >>  plpgsql_call_handler | $libdir/plpgsql |           11 >>  plpgsql_call_handler | /usr/lib/postgresql/8.4/lib/plpgsql.so >> |         2200 >> (2 filas) >> >> As you said, 2200 is public namespace/schema and 11 is pg_catalog. >> >> >> At the beginning of the backup file I can find these sentences: >> >> CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler >>     LANGUAGE c >>     AS '/usr/lib/postgresql/8.4/lib/plpgsql.so', >> 'plpgsql_call_handler'; <-- I've changed this line to use the right >> path to plpgsql.so library >> >> CREATE PROCEDURAL LANGUAGE plpgsql HANDLER plpgsql_call_handler; >> >> I guess these are the ones causing all of this. **What should be the >> best way to handle this situation?** Remove these lines and create >> the language explicitly when creating database? > > Just drop the 2nd function (in the public schema) : > drop function public.plpgsql_call_handler ( ) ; > and see pg_upgrade goes from there. > >> Or replace them with a create language sentence? Maybe something >> else? My final goal is migrate from 7.14 server to 8.4 server and >> after that (if I have an OK from the boss) upgrade 8.4 to the latest >> version that I can use. Server uses CentOS, and probably I won't be >> able to upgrade to v10 but I hope at least 9.5/9.6 will be available. > I've tested your suggestion and it went OK: restored db in 8.4, run "drop language" sentence, stopped services and run pg_upgrade --check which ended up with "Clusters are compatible". GREAT!! But... In one of my tests I forgot to change the path to plpgsql.so library, and when restoring db it gave me an error saying it could not access to the path given (of course, because that path only exists in the server, in my machine is different). After restoring with this error I found that: newdb=# select fn_now();      fn_now ----------------  20190923085521 (1 fila) newdb=# select proname,probin,pronamespace from pg_proc where proname='plpgsql_call_handler';        proname        |     probin      | pronamespace ----------------------+-----------------+--------------  plpgsql_call_handler | $libdir/plpgsql |           11 (1 fila) Which means that despite the error, language has been created. So in the end, not creating plpgsql_call_handler function and running "drop language" both leads me to the same result. I understood this piece of code [1] like: "create this language called plpgsql that will be interpreted by this function called plpgsql_call_handler wich code is in the library plpgsql.so". But with these results don't know the meaning of this code, as one of the solutions is drop language after creating, and the other one is create language without it's handler. I would appreciate an explanation about this, why is this happening or what am I misunderstanding. [1] this piece of code: CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler     LANGUAGE c     AS '/usr/lib/pgsql/plpgsql.so', 'plpgsql_call_handler'; CREATE PROCEDURAL LANGUAGE plpgsql HANDLER plpgsql_call_handler;