pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins?
Hi all, with a huge delay, I've seen this question [1]. . and it seems like the hstore.so was somewhat intimately integrated into OP's database so the '/usr/bin/pg_dump --schema-only --binary-upgrade --format=custom' called through 'pg_upgrade' failed with: pg_dump: [archiver (db)] query failed: ERROR: could not access file "$libdir/hstore": No such file or directory Which means that the dump from old datadir, with old server (without hstore.so packaged) failed. But playing with hstore.so a bit, the upgrade always worked smoothly for me even without the "old" hstore.so Googling around, I only found that there were some incompatible changes historically in hstore.so causing pg_upgrade failure; but this is different issue -- in the issue I talk about now the module was not found at all, even though it is usually even not searched for. So the question is what circumstances could cause this issue in particular? Is it expected in general that, to make the pg_upgrade run smooth, all the "loaded" server modules are built against and available for the --old-bindir server? Don't we have some reproducer for this kind of issues? [1] https://ask.fedoraproject.org/en/question/69316/postgresql-doesnt-work-after-upgrade-to-f22/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1557490 Thank for hints, Pavel
Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins?
On Wednesday, April 18, 2018 4:22:23 PM CEST Tom Lane wrote: > Pavel Raiskup writes: > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1557490 > > There are certainly plenty of reasons why extension .so's might be needed > during pg_dump, even in a binary-upgrade situation. The first example > that comes to mind is that an hstore-type constant appearing in a view > definition would require hstore_out() to be invoked while dumping the view > definition. Thanks for the example, Tom. I'll resolve the bug [2] then. Pavel
Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins?
On Wednesday, April 18, 2018 4:43:01 PM CEST Adrian Klaver wrote: > On 04/18/2018 07:22 AM, Tom Lane wrote: > > Pavel Raiskup writes: > >> . and it seems like the hstore.so was somewhat intimately integrated into > >> OP's database so the '/usr/bin/pg_dump --schema-only --binary-upgrade > >> --format=custom' called through 'pg_upgrade' failed with: > >>pg_dump: [archiver (db)] query failed: ERROR: could not access file > >>"$libdir/hstore": No such file or directory > >> Which means that the dump from old datadir, with old server (without > >> hstore.so packaged) failed. But playing with hstore.so a bit, the upgrade > >> always worked smoothly for me even without the "old" hstore.so > > > > Hi Pavel, > > > > There are certainly plenty of reasons why extension .so's might be needed > > during pg_dump, even in a binary-upgrade situation. The first example > > that comes to mind is that an hstore-type constant appearing in a view > > definition would require hstore_out() to be invoked while dumping the view > > definition. > > I am obviously missing something. If the old server was using hstore in > a database how could hstore.so could be accessible to it but not pg_dump? Because on Fedora we usually run pg_upgrade after distribution upgrade (e.g. for Fedora 27 => Fedora 28 upgrade it means also upgrade from PostgreSQL 9.6 to 10), and then we provide the old server in different package (postgresql-upgrade) which has limited feature set (including the missing hstore.so module). Pavel > > > > I don't remember anymore whether I'd set up the postgresql-update package > > to include the contrib modules for the old server version. If I didn't, > > it was an oversight :-(. > > > > regards, tom lane > > > > > > >
obsoleting plpython2u and defaulting plpythonu to plpython3u
Per current plpython docs: The language named plpythonu implements PL/Python based on the default Python language variant, which is currently Python 2. (This default is independent of what any local Python installations might consider to be their “default”, for example, what /usr/bin/python might be.) The default will probably be changed to Python 3 in a distant future release of PostgreSQL, depending on the progress of the migration to Python 3 in the Python community. .. the status quo seems to be bit optimistic with the "distant future", and we should start thinking about dropping plpython2 support, same as upstream (a bit optimistically too, IMO) does [1]. The docs don't suggest the explicit use of plpython2, but still the docs are not discouraging from it -- so it is likely some clusters run against that. What's the expected future migration path from plpython2 to plpython3 in such cases? I'm thinking about rewrite of the docs and creating some scripting which could simplify the migration steps. Would such patches be welcome at this point? [1] https://pythonclock.org/ Pavel
Re: Who and How is responsible for released installations packages and 3rd party packs? (e.g. on https://yum.postgresql.org/9.6/redhat/rhel-7.3-x86_64/)
On Friday, August 3, 2018 8:08:55 AM CEST Devrim Gündüz wrote: > On Thu, 2018-08-02 at 16:26 +0300, Alexandru Lazarev wrote: > > What about 3rd party libraries like plv8 - Who and How (based on which > > criteria, which versions) build RPM and upload them there? > > Latest versions of PL/v8 does not build on RHEL/Fedora anymore, at least from > the package build point of view. Yes, packaging of plv8 is pretty complicated. If one decided to ship RPM package with plv8, it would mean maintenance of whole v8 language - which is incredibly complicated (incompatible changes all the time, backporting security fixes, etc.). That's the reason why plv8 (and even v8 runtime) becomes dropped from Linux distributions. [1] https://github.com/plv8/plv8/issues/281 Pavel
