From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Rob Sargent <robjsargent(at)gmail(dot)com>, Devrim Gündüz <devrim(at)gunduz(dot)org>, Marcin Giedz <marcin(dot)giedz(at)arise(dot)pl>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Magnus Hagander <magnus(at)hagander(dot)net>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade from 12 to 13 failes with plpython2 |
Date: | 2020-11-19 06:11:00 |
Message-ID: | 1026148.1605766260@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian <bruce(at)momjian(dot)us> 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. The generic
problem is how to usefully identify some functions that have dangling
probin pointers. I don't want a solution that only works for the
plpython functions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Apitz | 2020-11-19 07:38:45 | \COPY command and indexes in tables |
Previous Message | Paul Förster | 2020-11-19 06:04:43 | Re: create type with %type or %rowtype |