Hi,
On Tue, 2020-11-17 at 14:30 -0800, Adrian Klaver wrote:
> As a packager you are in charge of how the packaging is done. Still
> announcing a change that effectively nullifies the documentation
> would to me be something that should be announced somewhere else
> than a list that I'm guessin
Bruce Momjian writes:
> It didn't trigger this message for him, and I am also wondering if it
> should have.
The extra functions in this case were in pg_catalog, not public,
so there is exactly no part of that error message that is applicable.
In any case, that seems an overly specific solution.
On Wed, Nov 18, 2020 at 10:57:00PM -0700, Rob Sargent wrote:
> > It issues this message and fails:
> >
> >if (PQntuples(res) > 0)
> >{
> >if (!found_public_plpython_handler)
> >{
> >pg_log(PG_WARNING,
> >
> On Nov 18, 2020, at 9:39 PM, Bruce Momjian wrote:
>
> On Wed, Nov 18, 2020 at 09:35:20PM -0700, Rob Sargent wrote:
>>> pg_upgrade does have some code to handle plpython call handlers in
>>> function.c:get_loadable_libraries();
>>>
>>>* Systems that install plpython before 8.1 have
On Wed, Nov 18, 2020 at 09:35:20PM -0700, Rob Sargent wrote:
> > pg_upgrade does have some code to handle plpython call handlers in
> > function.c:get_loadable_libraries();
> >
> > * Systems that install plpython before 8.1 have
> > * plpython_call_handler() defined in the "public"
> On Nov 18, 2020, at 9:29 PM, Bruce Momjian wrote:
>
> On Wed, Nov 18, 2020 at 10:06:17PM +, Devrim Gunduz wrote:
>> Hi,
>>
>> On Wed, 2020-11-18 at 14:54 -0500, Tom Lane wrote:
>>> Uh-huh, so there you have it. These must be leftovers from some
>>> pre-extension incarnation of plpython
On Wed, Nov 18, 2020 at 10:06:17PM +, Devrim Gunduz wrote:
> Hi,
>
> On Wed, 2020-11-18 at 14:54 -0500, Tom Lane wrote:
> > Uh-huh, so there you have it. These must be leftovers from some
> > pre-extension incarnation of plpython that was never cleaned up
> > properly.
>
> I think this was
Hi,
On Wed, 2020-11-18 at 14:54 -0500, Tom Lane wrote:
> Uh-huh, so there you have it. These must be leftovers from some
> pre-extension incarnation of plpython that was never cleaned up
> properly.
I think this was broken when Marcin first dropped the language. We
should just have dropped the
Bruce Momjian writes:
> On Wed, Nov 18, 2020 at 03:25:56PM -0500, Tom Lane wrote:
>> Maybe pg_upgrade should print the actual function names, not just the
>> probin values.
> It is done that way so we don't overwhelm them with lots of function
> names, and they can focus on the library. I was th
On Wed, Nov 18, 2020 at 03:25:56PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I think one big problem is that when pg_upgrade fails in this way, users
> > are required to do some complex system catalog queries to diagnose the
> > cause. Is there a way to simplify this for them?
>
> Maybe
Bruce Momjian writes:
> I think one big problem is that when pg_upgrade fails in this way, users
> are required to do some complex system catalog queries to diagnose the
> cause. Is there a way to simplify this for them?
Maybe pg_upgrade should print the actual function names, not just the
probi
On Wed, Nov 18, 2020 at 08:59:58PM +0100, Marcin Giedz wrote:
>
> > anyway got this from your query:
>
> > 16402 | plpython_call_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | f
> | f | v | u | 0 | 0 | 2280 | | | | | | | plpython_call_handler | $libdir/
> plpython2 | |
> > 16403 | plpython_
> anyway got this from your query:
> 16402 | plpython_call_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | f
> | f | v | u | 0 | 0 | 2280 | | | | | | | plpython_call_handler |
> $libdir/plpython2 | |
> 16403 | plpython_inline_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f |
> t | f
Marcin Giedz writes:
> anyway got this from your query:
> 16402 | plpython_call_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | f
> | f | v | u | 0 | 0 | 2280 | | | | | | | plpython_call_handler |
> $libdir/plpython2 | |
> 16403 | plpython_inline_handler | 11 | 10 | 13 | 1 | 0 | 0 | - |
[ please don't top-post, it makes conversations unreadable ]
Marcin Giedz writes:
> so look at this:
> postgres=# drop extension plpython;
> ERROR: extension "plpython" does not exist
> postgres=# drop extension plpythonu;
> ERROR: extension "plpythonu" does not exist
> postgres=# drop ex
[ please don't top-post, it makes conversations unreadable ]
Marcin Giedz writes:
> so look at this:
> postgres=# drop extension plpython;
> ERROR: extension "plpython" does not exist
> postgres=# drop extension plpythonu;
> ERROR: extension "plpythonu" does not exist
> postgres=# drop exten
st
argosrm=# drop extension plpython2u;
ERROR: extension "plpython2u" does not exist
Od: "Tom Lane"
Do: "Marcin Giedz"
DW: "Laurenz Albe" , "Magnus Hagander"
, "Adrian Klaver" , "Devrim
Gündüz" , "pgsql-general&qu
Marcin Giedz writes:
> all DBs checked and no plpython(2u) is found except for plpython3u
I think you also need to make sure you've dropped the plpythonu
and plpython2u extensions in every database.
regards, tom lane
Hagander"
DW: "Adrian Klaver" , "Tom Lane"
, "Devrim Gündüz" , "pgsql-general"
Wysłane: środa, 18 listopad 2020 12:58:45
Temat: Re: pg_upgrade from 12 to 13 failes with plpython2
On Wed, 2020-11-18 at 11:05 +0100, Marcin Giedz wrote:
> ri
On Wed, 2020-11-18 at 11:05 +0100, Marcin Giedz wrote:
> right, I had one function relaying on plpython2u so I changed it... but the
> again pg_upgrade claims error with python:
>
> cat loadable_libraries.txt
> could not load library "$libdir/plpython2": ERROR: could not access file
> "$libdir
ne_handler |
plperlu_validator | $libdir/plperl |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler |
plpython3_validator | $libdir/plpython3 |
(6 rows)
template1=#
Od: "Magnus Hagander"
Do: "Marcin Giedz"
DW: "Adrian Klaver" , "
On Wed, Nov 18, 2020 at 8:11 AM Marcin Giedz wrote:
>
> but my question still remains the same - what causes pg_upgrade failure - are
> functions the reason? what I did was to delete these 2 rows from
> pg_pltemplate as I thought this may help:
>
> postgres=# delete from pg_pltemplate where tmpl
düz" , "Tom Lane"
DW: "Marcin Giedz" , "pgsql-general"
Wysłane: wtorek, 17 listopad 2020 23:30:44
Temat: Re: pg_upgrade from 12 to 13 failes with plpython2
On 11/17/20 2:17 PM, Devrim Gündüz wrote:
>
> Hi,
>
> On Tue, 2020-11-17 at 16:23 -0
On 11/17/20 2:17 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote:
You're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support.
The packagers frequently don't have a lot of choice in the matt
Hi,
On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote:
> You're confusing what the source code can do (which is what the
> manual documents) versus what individual packagers choose to support.
> The packagers frequently don't have a lot of choice in the matter;
> once their platform drops python2
On 11/17/20 1:23 PM, Tom Lane wrote:
Adrian Klaver writes:
It would be nice to mention this on --announce and here as this still
exists:
https://www.postgresql.org/docs/13/plpython-python23.html
You're confusing what the source code can do (which is what the
manual documents) versus what indi
Adrian Klaver writes:
> It would be nice to mention this on --announce and here as this still
> exists:
> https://www.postgresql.org/docs/13/plpython-python23.html
You're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support
Hi,
On Tue, 2020-11-17 at 13:18 -0800, Adrian Klaver wrote:
> > https://www.postgresql.org/message-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel%40gunduz.org
>
> So to be clear what was dropped was plpythonu, which means
> plpython2u. plpython3u still exists, correct?
Right.
Regards,
--
D
On 11/17/20 12:49 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 12:18 -0800, Adrian Klaver wrote:
This was announced where and when?
https://www.postgresql.org/message-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel%40gunduz.org
So to be clear what was dropped was plpythonu, which m
Hi,
On Tue, 2020-11-17 at 12:18 -0800, Adrian Klaver wrote:
> This was announced where and when?
https://www.postgresql.org/message-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel%40gunduz.org
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @Devr
On 11/17/20 12:06 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote:
Hi all, trying to performe upgrade from 12 to 13 installed from
Centos8 repo gives such error:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access
f
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote:
>> Hi all, trying to performe upgrade from 12 to 13 installed from
>> Centos8 repo gives such error:
>>
>> cat loadable_libraries.txt
>> could not load library "$libdir/plpython2": ERROR: could n
Hi,
On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote:
> Hi all, trying to performe upgrade from 12 to 13 installed from
> Centos8 repo gives such error:
>
> cat loadable_libraries.txt
> could not load library "$libdir/plpython2": ERROR: could not access
> file "$libdir/plpython2": No such
Hi all, trying to performe upgrade from 12 to 13 installed from Centos8 repo
gives such error:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file
"$libdir/plpython2": No such file or directory
digging around:
1.
drop extension plpythonu;
ER
34 matches
Mail list logo
