Re: pg_upgrade Python version issue on openSUSE

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Paul Förster <paul(dot)foerster(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade Python version issue on openSUSE
Date: 2020-09-27 17:32:00
Message-ID: c0110301-5fc0-b2f0-7659-8e7df14cc847@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/27/20 10:30 AM, Adrian Klaver wrote:
> On 9/27/20 2:00 AM, Paul Förster wrote:
>> Hi Adrian,
>>
>>> On 27. Sep, 2020, at 00:09, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
>>> wrote:
>>> Could it be that at some point in these instances history plpython*
>>> where installed as CREATE LANGUAGE and you are dealing with the
>>> vestiges of that?
>>
>> I do know for sure that that never happened because the database
>> clusters with this effect are my personal test databases and I never
>> used Python. I did some tests with plperl and plperlu, though, but
>> never python, because I don't "speak" python.
>>
>> What is possible is, those databases are clones of a Patroni cluster
>> database (primary) I used to experiment with. I just copied them to
>> new PGDATAs back then and changed PGPORT of course. I know, I could
>> have done initdb and pg_dumpall but just copying the whole database
>> cluster was the fast way to go, even more so as the PostgreSQL
>> software was exactly the same. Just PGDATA and PGPORT changed for the
>> clone. From what I know this is a perfectly legal way to do it as long
>> as the source database cluster is properly shut down during the copy
>> process.
>>
>> Maybe Patroni did it then implicitly? I'm not sure how Patroni works
>> internally but I know that it is written in Python. Maybe it does
>> install something in the database which I don't know and can't find? I
>> tried searching for anything owned by "replicator" but can't find
>> anything.
>>
>>> Are you able to go back and reconstruct them and then do \dL
>>> (languages) and \dx (extensions)?
>>
>> The machine in question is my personal test box at home. I don't do
>> regular backups there. If I break something I just reinstall it. So
>> going back into the past with backups is not possible for me. The only
>> thing that I kept running a long time now is the Patroni cluster
>> because I have some data stored in it. But this is the only "history"
>> there is. However, \dx and \dL do not show any Python extension or
>> language on the Patroni cluster too, which is still 12.4.
>
> Does:
>
> SELECT
>     lanname, proname, probin
> FROM
>     pg_proc
> JOIN
>     pg_language
> ON
>     pg_language.oid = pg_proc.prolang
> WHERE
>     pg_language.lanname='plpythonu'
> AND
>    probin IS NOT NULL;
>
> show anything? This would need to be repeated for each cluster in database.

Really? Make that for each database in cluster!

>
>>
>> Still, thanks for helping.
>>
>> Cheers,
>> Paul
>>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Chris Stephens 2020-09-27 20:54:55 help flattening json
Previous Message Adrian Klaver 2020-09-27 17:30:31 Re: pg_upgrade Python version issue on openSUSE