PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

BŁĄD:nie można uzyskać dostępu do pliku „$libdir/plpython2” – BŁĄD:nie można uzyskać dostępu do pliku „$libdir/plpython3”

Powyższy błąd opisany przy wysyłaniu PG, ponieważ nie można TWORZYĆ JĘZYKA plpython2u/plpython3u w PG9.3Beta.

Error:
postgres=# create language plpython3u;
ERROR: could not access file "$libdir/plpython3": No such file or directory

postgres=# create language plpython2u;
ERROR: could not access file "$libdir/plpython2": No such file or directory

Przed przestudiowaniem powyższych błędów przeczytałem poniższy link do dokumentacji PG o tym, jak PostgreSQL pozwala na tworzenie języka plpython i jak powinny być skonfigurowane.

http://www.postgresql.org/docs/9.3/static/plpython-python23.html

Z powyższego linku jest jasne, że musisz skompilować plik binarny dwa razy, jeśli potrzebujesz zarówno plpython2u, jak i plpython3u. AFAIK, ActivePython 2.7.x dla plpython2u i 3.2.x dla plpython3u można skonfigurować na PG 9.2.x bez żadnych trudności, ale nigdy nie próbowałem PG 9.3Beta2. Tak więc, aby spróbować i przeanalizować błąd dotyczący tego, dlaczego i jak można go naprawić, najpierw rozpocząłem instalację źródła, ustawiając ścieżkę bazową za pomocą ActivePython 3.2. (Łącze pobierania ActivePython http://www.activestate.com/activepython/downloads)

[root@localhost postgresql-9.3beta1]# export PATH=/opt/ActivePython-3.2/bin:$PATH
[root@localhost postgresql-9.3beta1]# ./configure --prefix=/usr/local/pg93b --with-python

Kompilacja nie powiodła się i pokazała błąd w pliku Config.log jako:

make[3]: Entering directory `/usr/local/src/postgresql-9.3beta1/src/pl/plpython'
*** Cannot build PL/Python because libpython is not a shared library.
*** You might have to rebuild your Python installation. Refer to
make[3]: Leaving directory `/usr/local/src/postgresql-9.3beta1/src/pl/plpython'

W dokumentacji PG mamy jasne wskazówki dotyczące powyższego błędu i dlaczego tak się dzieje, plpython będzie biblioteką współdzieloną na większości platform, ale na niektórych platformach musimy specjalnie wymusić kompilator jako python z biblioteki współdzielonej. W tym celu możesz przejść do /src/pl/python/Makefile dla zmian lub konkretnie podać „shared_libpython=yes” podczas kompilacji.

Kompilacja źródeł sprawdza dwa pliki, gdy używasz –with-python, które są „python” i „python-config”. Chociaż mam ActivePython-3.2 w mojej podstawowej ścieżce, nadal kompilator nie może ich znaleźć „python” i „python-conifg”

[root@localhost postgresql-9.3beta1]# which python
/usr/local/bin/python
[root@localhost postgresql-9.3beta1]# which python-config
/usr/local/bin/python-config

Dzieje się tak dlatego, że w ActivePython 3.2 nazwy plików będą „python” jako „python3” i „python-config” jako „python3-config”, dlatego kompilator wskazał na stary zamiast na nowy. W tym momencie Asif Naeem (Dziękuję za wgląd) od naszego podstawowego Dev. Zespół powiadomił mnie, abym podszywał istniejące pliki ActivePython-3.2 jako python i python-config. To prawie jak włamanie z jego strony, więc zduplikowałem te pliki jako:

cd /opt/ActivePython-3.2/bin
cp python3-config python-config
cp python3 python

Ok, teraz widzę to w mojej podstawowej ścieżce.

[root@localhost postgresql-9.3beta1]# export PATH=/opt/ActivePython-3.2/bin:$PATH
[root@localhost postgresql-9.3beta1]# which python
/opt/ActivePython-3.2/bin/python
[root@localhost postgresql-9.3beta1]# which python-config
/opt/ActivePython-3.2/bin/python-config

Przekompilowałem źródło PG przy użyciu –with-python po zmianach, a także zmusiłem kompilator do wybrania SHARED_LIBPYTHON przy użyciu „shared_libpython”.

./configure --prefix=/usr/local/pg93b3 --with-python
make shared_libpython=yes
make shared_libpython=yes install

Te kroki skutecznie skompilują PG9.3Beta z bibliotekami ActivePython-3.2. Teraz utwórzmy język plpython3u:

-bash-4.1$ psql -p 4444
psql (9.3beta1)
Type "help" for help.

postgres=# create language plpython3u;
The connection to the server was lost. Attempting reset: Failed.
!>
!>

Ups, to dziwne, dlaczego teraz się zawiesił.. W takiej sytuacji $PGDATA/pg_log są twoimi przyjaciółmi, aby dowiedzieć się o problemie. Oto informacje dziennika serwera bazy danych dotyczące awarii:

2013-07-13 22:08:37 IST-31208-postgres-postgres :LOG: statement: create language plpython3u;
Could not find platform independent libraries
Could not find platform dependent libraries
Consider setting $PYTHONHOME to [:]
Fatal Python error: Py_Initialize: Unable to get the locale encoding

Ok. Brakowało mi ustawienia ścieżek Pythona, jest to bardzo ważne, gdy pracujesz z językami Pythona lub Perl w swojej bazie danych.
Ustawiłem PYTHONHOME, PYTHONPATH i LD_LIBRARY_PATH przed uruchomieniem klastra.

export PYTHONHOME=/opt/ActivePython-3.2/
export PYTHONPATH=/opt/ActivePython-3.2/bin:$PATH
export LD_LIBRARY_PATH=/opt/ActivePython-3.2/lib:$LD_LIBRARY_PATH

/usr/local/pg93b3/bin/pg_ctl -D /usr/local/pg93b3/data/ start

-bash-4.1$ psql -p 4444
psql (9.3beta1)

Type "help" for help.

postgres=# create language plpython3u;
CREATE LANGUAGE

Fajnie… Stworzył plpython3u z ActivePython-3.2.

Jeśli chcesz plpython2u również na tej samej instalacji. Nie modyfikuj, jak to zrobiliśmy w przypadku ActivePython-3.2, po prostu miej kopię ActivePython-2.7 i ustaw ją w ścieżce podstawowej i ponownie skompiluj źródło.

export PATH=/opt/ActivePython-2.7/bin:$PATH
./configure --prefix=/usr/local/pg93b2 --with-python
make shared_libpython=yes
make shared_libpython=yes install


export PYTHONHOME=/opt/ActivePython-2.7/
export PYTHONPATH=/opt/ActivePython-2.7/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/pg93b2/lib
export LD_LIBRARY_PATH=/opt/ActivePython-2.7/lib:$LD_LIBRARY_PATH

-bash-4.1$ ./psql -p 4444
psql (9.3beta2)
Type "help" for help.

postgres=#
postgres=# create language plpython2u;
CREATE LANGUAGE

Komentarze i poprawki są mile widziane.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. JPA Nazwy tabel pisane wielkimi literami

  2. Wzorce i modyfikatory szablonów do formatowania liczb w PostgreSQL

  3. Użytkownik Postgresa nie istnieje?

  4. W obronie sar (i jak to skonfigurować)

  5. PostgreSQL CASE ... END z wieloma warunkami