58p01 ошибка нет доступа к файлу libdir mchar no such file or directory
Describe the bug
Postgresql showing the error message could not access file "$libdir/timescaledb-1.4.0": No such file or directory on any psql command like SELECT * .
It says the extension is up to date. I don't understand what's going on.
From inside docker image, here is the output of:
Thanks for your help!
The text was updated successfully, but these errors were encountered:
RobAtticus commented Sep 4, 2019
It appears our docker image may be missing some of the libs you need, rebuilding and pushing.
RobAtticus commented Sep 4, 2019
Okay @waterdrop01 , if you pull the new alpine images it should work now. It should have the missing .so s
waterdrop01 commented Sep 5, 2019
Thanks @RobAtticus , pulling newest docker image fixed the issue
gp-hardik commented Oct 18, 2019
Hi @RobAtticus I am facing the same issue while updating from 1.1.0 . The pg_config --pkglibdir
doesn't show 1.1.0.so file and the ERROR: could not access file "$libdir/timescaledb-1.1.0": No such file or directory ; is still pertaining. I have tried pulling the latest docker image using timescale/timescaledb:latest-pg10 but still no luck.
skrenes commented Nov 26, 2019
I had the same issue when I upgraded my timescale/timescaledb:latest-pg11 container, which I believe is v1.5.1. The exact error message I was receiving was: ERROR: could not access file "$libdir/timescaledb-1.3.1": No such file or directory
I explicitly set the image to timescale/timescaledb:1.5.0-pg11 and it worked just fine. Can we reopen this issue or is it better to create a new one and perhaps reference this one?
RobAtticus commented Nov 26, 2019
@skrenes I will double check the image to make sure it has some older versions, but in the interest of keeping our images small, we like to restrict it to the last ~5 TimescaleDB versions or so. So if you were coming from 1.3.1, that's probably why 1.5.0 worked (has 1.4.2, 1.4.1, 1.4.0, 1.3.2, and 1.3.1) and 1.5.1 did not (has 1.5.0 down to 1.3.2).
RobAtticus commented Nov 26, 2019
Which also means you should be able to upgrade to 1.5.1 now that you've gone to 1.5.0
RobAtticus commented Nov 26, 2019
I just checked and it looks like that was the issue. the 1.5.1 image has back to 1.3.2 :) So now you should be able to update
skrenes commented Nov 26, 2019
Thanks for your rapid response @RobAtticus
I just tried upgrading again and got the same error. I went back to 1.5.0. and did a maintenance routine on both my databases (vacuum full, reindex, etc) and then tried 1.5.1. again and still got the same error. Any ideas?
I'm not sure why it references 1.3.1 in the error. I've regularly stayed up to date, and as I've said, I was on 1.5.0 before the upgrade.
skrenes commented Nov 26, 2019
Oh, I was not aware of the instructions for upgrading docker containers. After running ALTER EXTENSION timescaledb UPDATE; I was able to use the latest container without problems. Thank you for your help! Any chance the container can do this itself upon detecting an older extension?
RobAtticus commented Nov 27, 2019
@skrenes Ah yes, you need to run ALTER EXTENSION . We can definitely look into auto-altering.
tmtron commented May 5, 2020 •
I also just hit this issue - in my case, I have updated our database (called daqmon) - but still got this error. It turned out, that we also had to run ALTER EXTENSION in the postgres database.
So the full sequence is:
Note: since we don't need timescaledb in the postgres database we can "uninstall" it
anka commented Jun 3, 2020
@RobAtticus I am facing the same issue after upgrading from 1.4.0 to 1.7.1. It tells me ERROR: could not access file "$libdir/timescaledb-1.4.0": No such file or directory . I did run the ALTER statement but this did not fix the problem.
RobAtticus commented Jun 3, 2020
@anka For size considerations, we do not include every older version in the Docker image. You will have to do a transitional upgrade. So if you try upgrading to 1.5.0 or 1.6.0 first, it should work.
tmtron commented Jun 3, 2020
@RobAtticus do we really need transitional upgrades?
The upgrade docs say:
ALTER EXTENSION timescaledb UPDATE;
This will upgrade TimescaleDB to the latest installed version, even if you are several versions behind.
So these docs are wrong/outdated?
Just today I've updated an docker installation from 1.4 to 1.7.
When I connected with psql -X
- \dx reported this No such file or director error
- but after ALTER EXTENSION timescaledb UPDATE; it worked an reported the new version.
Did I miss something?
Or maybe it just worked, because this instance had no hypertables, yet?
RobAtticus commented Jun 3, 2020
@tmtron Yes because the docker images do not contain all previous libraries. Perhaps the docs could be a bit more specific, but it does usually contain at least the previous 5 versions.
RobAtticus commented Jun 3, 2020
@tmtron In your case it sounds like it worked though. If \dx shows the correct version, then you are good to go.
tmtron commented Jun 3, 2020
@RobAtticus thanks for the fast reply - just one clarification please:
it does usually contain at least the previous 5 versions.
does it count all versions - also patch-level?
e.g. 1.4.2, 1.5.0, 1.5.1, 1.6.0, 1.7.0
- = 5 versions (because 1.5.0 and 1.5.1 are different)
- or only 4 (because 1.5.0 and 1.5.1 are the same)
RobAtticus commented Jun 3, 2020 •
Yes, patch level are their own version.
So 1.7.1 contains these versions in addition to 1.7.1:
So if you are using Docker and on a version older than that, you first need to upgrade to one of those and then to 1.7.1
tmtron commented Jun 3, 2020
@RobAtticus thanks for the info!
seems I was right on time to upgrade my 1.4.2. version :)
anka commented Jul 29, 2020
So I did update from 1.4.0 to 1.6.0 to 1.7.2 and now I get the following error within the log files. However, the database starts correctly.
However \dx timescaledb shows 1.7.2 and everything seems to work correctly. Is there anything more I can check if something is missing?
RobAtticus commented Jul 29, 2020
@anka You might have other databases that you need to run ALTER EXTENSION in? It has to be run in each database where Timescale is installed, not just one
anka commented Jul 30, 2020
@RobAtticus actually not, there is only one database. It looks like the upgrade by using ALTER EXTENSION did work but the error is still visible in the log files when restarting postgres.
tmtron commented Jul 30, 2020
@anka in psql use \l to see all databases.
We usually have one database with a custom name and sometimes forget to update the (unused) postgres database.
I think once, I even had to update template0
drm commented Jun 7, 2021 •
FWIW: For me, an ALTER EXTENSION timescaledb UPDATE was sufficient to fix a similar issue.
Немного дополню ваш вопрос, а потом расскажу решение речь идет про Linux сервер и бд Postgre о этом говорит порт: 5432 и это и есть корень вашей проблемы.
И ошибка ваша выглядит так:
Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
РЕШЕНИЕ:
1. нужно проверить на сервере есть ли в открытых портах 5432 и сам postgresql
Должно быть примерно так, если у вас пусто или вот так:
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 1439/postgres
Pезультат выполнения команды означает, что PostgreSQL принимает подключения по адресу 127.0.0.1 и порту 5432. Чтобы изменить настройки, понадобится отредактировать файл postgresql.conf
Найти местонахождение файла можно командой:
$ find / -name postgresql.conf 2> /dev/null
/etc/postgresql/10/main/postgresql.conf
Надо указать PostgreSQL, что необходимо принимать подключения по всем адресам:
listen_addresses = '*'
и перезагрузить СУБД:
service postgresql restart
Также можно прямо с сервера проверить подключение постгресскуэль
psql -U my_login -h 192.168.0.14 postgres
Если сервер доступен, то будет получен доступ к базе данных postgres:
psql
Type "help" for help.
ОЧЕНЬ ВАЖНО
Залезьте в лог постгре cat /var/log/postgresql/postgresql-10-main.log
И если у вас там: ВАЖНО: нет доступа к файлу "online_analyze": Нет такого файла или каталога
и до этого у вас все работало на вашей убунте и postgres и тут после рестарта все сломалось, предположу что вы обновили убунту.
libpq5/bionic-security,bionic-updates 10.6-0ubuntu0.18.04.1 amd64 [может быть обновлён с: 10.5-10.1C]
postgresql-10/bionic-security,bionic-updates 10.6-0ubuntu0.18.04.1 amd64 [может быть обновлён с: 10.5-10.1C]
postgresql-client-10/bionic-security,bionic-updates 10.6-0ubuntu0.18.04.1 amd64 [может быть обновлён с: 10.5-10.1C]
И вероятно починив порт 5432 и создав online_analyze
у вас будет ошибка: error could not access file $libdir/mchar no such file or directory
РЕШЕНИЕ:
1. Качайте дистрибутив с сайта 1С и переустанавливайте его.
2. И блокируйте обновления постгрес:
sudo apt-mark hold libpq5:amd64 postgresql-10 postgresql-client-10
В один прекрасный вечер произошла неприятная ситуация, сервер физически перестал запускаться. Сисадмин после осмотра объявил о неисправности обоих дисков из зеркального рейда. Просто как выиграть в лотерею))). Бекап базы был не очень далекий, но все-таки хотелось восстановить базу 1С полностью, чтобы не потерять даже одного дня работы. Диск отвезли в специализированную контору, и за ночь они выудили что смогли с этих дисков.
Естественно, не обошлось без потерь. На сервере стоял сервер PostgreSQL и, следовательно, меня интересовала папка из его рабочего каталога data. На новом компьютере установил postgresql с нуля. той же версии, что и стоял на упавшем сервере, с теми же настройками. Остановил службу чистоустановленного postresql , заменяю папку data в рабочем каталоге postreSQL (обычно это находится примерно там - C:\Program Files (x86)\PostgreSQL\9.0.3-3.1C\), восстановленной специалистами с битого диска. Запускаем службу PostgreSQL. У меня она не сразу запустилась. После некоторых экспериментов выяснил, что при копировании папки слетели права на нее и служба не могла ее прочитать и не стартовала из-за этого. Настроил права на каталог data - все взлетело))) Чудо, даже 1С запустился конфигуратор)))
А вот дальше ждал неприятный сюрприз. При попытке выгрузить базу в dt вылетала ошибка СУБД ERROR: could not open file ''base/33264/49743'': No such file or directory. Тестирование и исправление вылетало с той же ошибкой. Видимо специалисты не все файлы таблиц postgresql восстановили.
Я решил проблему следующим образом. Сохранил структуру конфигурации в cf файл. При тестировании и исправлении по строке состояния заметил, на каком объекте падает тестирование. У меня это оказался регистр накопления. Я его удалил, обновил базу данных. а потом заменил конфигурацию базы данных на сохраненную ранее в cf. При таких действиях таблица создастся заново, но данные из нее будут потеряны.
Мне повезло, что пострадала только одна таблица, и это оказался регистр накопления. Его легко можно заполнить заново, перепроведя документы. Если бы пострадал какой нибудь справочник или документ, было бы, конечно, хуже, данные оттуда уже нельзя было бы восстановить так просто. Могла также пострадать какая-нибудь системная таблица 1С и тогда конфигурация вообще не открылась бы. Мой путь решения не идеален, но в моем случае помог восстановить базу полностью. Может, кому поможет мой опыт))
Great App for development! I'm pumped to use it, but I am getting the following error when trying to create a stored procedure.
Any idea what might be wrong? Or how I can fix it?
I've confirmed that plpgsql.so is in that directory.
Should have mentioned that my version is reported as Version 9.2.2.0 (20). I just downloaded it a few days ago.
The text was updated successfully, but these errors were encountered:
croxey commented Mar 29, 2013
A work around. I found that if I restored a database from a postgres dump I
could get around the error.
Did you ever sort this out? I am having the same problem.
mattt commented May 1, 2013
There was an issue with the plpgsql that shipped with that version. It's fixed on master now, and will hopefully be working with the forthcoming release.
vjpr commented May 6, 2013
Same problem. Just downloaded 9.2.4.1 and its still broken.
vjpr commented May 6, 2013
@mattt Is there a workaround I can use before the next release?
vjpr commented May 7, 2013
@mattt Just rebuilt from master and copied across plpgsql.so , restarted server. It didn't fix it.
vjpr commented May 7, 2013
Also it seems more of an issue with $libdir rather than plpgsql :
A post from this page:
ERROR: could not access file "$libdir/postgis-2.0": No such file or directory
Retrieve postgis-2.0.so from postgis package for version postgresql 9.1 () and copy it to /opt/pgsql-9.1/lib (make sure the privileges are right)
This makes me think it could be a permission problem or that the compiled-in $libdir directory is incorrect or local to mattt's machine.
If the name starts with the string $libdir, that part is replaced by the PostgreSQL package library directory name, which is determined at build time.
alopix commented Aug 31, 2013
After downloading the latest version I encounter the exact same problem with postgis:
ERROR: could not access file "$libdir/postgis-2.0": No such file or directory
I desperately need postgis. Is there a workaround or will there be an updated version soon?
jakob commented Aug 31, 2013
If that doesn't help, try deleting the data directory (~/Library/Application Support/Postgres), maybe there's an issue with a previous installation.
Am 31.08.2013 um 13:57 schrieb Dustin notifications@github.com:
After downloading the latest version I encounter the exact same problem with postgis:
ERROR: could not access file "$libdir/postgis-2.0": No such file or directoryI desperately need postgis. Is there a workaround or will there be an updated version soon?
—
Reply to this email directly or view it on GitHub.
alopix commented Aug 31, 2013
As far as I can see it, this only happens on old databases because postgis-2.0 is missing, so migrating to the newer 2.1 is not possible.
There should be some mechanism to do that because otherwise we'll be stuck with old postgres.apps :(
jakob commented Aug 31, 2013
If I understand correctly this means we would have to include PostGIS 2.0 AND PostGIS 2.1 in Postgresapp.
Here's a temporary workaround: Copy postgis-2.0.so , rtpostgis-2.0.so , and a few files named liblwgeom.* from the old PostgresApp to the new version. They are located in $libdir , which is inside the app package. To show that file, right click on the app and select "Show Package Contents". The directory containing the libraries is Contents/MacOS/lib .
Then open the new Postgres.app, and execute the following query:
This should allow you to upgrade to PostGIS 2.1
jakob commented Aug 31, 2013
I just realised overwriting liblwgeom with the old version might not be a good idea. Better copy just postgis-2.0.so and rtpostgis-2.0.so
alopix commented Aug 31, 2013
Yeah, that's what I figured. Maybe not include both versions but offer an update script that includes the old one and can migrate a database.
MRigal commented Sep 23, 2013
I had the same problem after switching from 2.0 to 2.1 ! Would be great to have something for being able to migrate the PostGIS DB !
jakob commented Sep 23, 2013
JerrySun363 commented Nov 2, 2013
Still getting the error
ERROR: could not access file "$libdir/plpgsql": No such file or directory
on my mavirick system.
Don't figure out why. And it still cannot't be found after I made a soft link there.
marnen commented Dec 23, 2013
@jakob Thanks for making 9.2.4.4 available! I've been having a strange time upgrading my DBs. I used 9.2.4.4 to upgrade all DBs that had PostGIS from 2.0 to 2.1, but when I then upgrade from 9.2 to 9.3, I still get it complaining about missing $libdir/postgis-2.0. Any ideas?
thesteve0 commented Jan 1, 2014
Just upgraded to Fedora 20 from Fedora 19. F20 ships with
postgresql-9.3.2-2.fc20.x86_64
and
postgis-2.1.1-1.fc20.x86_64
When I try to upgrade using this step
pg_dump: [archiver (db)] query failed: ERROR: could not access file "$libdir/postgis-2.0": No such file or directory
pg_dump: [archiver (db)] query was: SELECT pg_catalog.pg_get_viewdef('51422'::pg_catalog.oid) AS viewdef
So something is still not working. We hit this early on with builds in OpenShift as well.
Something is still broken in the migrators. Can we please get a fix. Luckily I don't have any real data in this db
jakob commented Jan 2, 2014
@thesteve0 When you update from PostGIS 2.0 to PostGIS 2.1 you need to make sure you have BOTH binaries installed. Might be easier to use pg_dump on your old system and then restore the database on the new system.
Anyway, this is completely unrelated to Postgres.app. Also, as far as I know this issue is fixed in the newest release of Postgres.app, and therefore I am closing this issue before other googlers stumble upon this and believe this is still relevant.
I have a database based on PG11, installed all necessary details, from sqlplus i have access to database, but I don't know how to fix this problem. I can't find where this library is created and located. "echo $libdir" didn't help to me. It shoes nothing. I don't have an possibility to change version of PG, so what can i do to install oracle_fdw successfully? System: CENTOS 7
The text was updated successfully, but these errors were encountered:
AlexDevLer commented Sep 24, 2019
Yes, im using PostgreSQL v11. At the beginning, i installed all oracle packages v19.3 like a sqlplus and so on. After this, i checked connection to oracle database via ./sqlplus. Im using PG v11.3, psql 9.2.24. Later I downloaded oracle_fdw package to home directory and unzipped it. After that, I installed it by makefile, entered as postgres user, wrote "create extension oracle_fdw" and catck the this error. I have solved this problem by copying the file "oracle_fdw.so" to usr/pgsql-11/bin. But, i catch the next error "ERROR: could not load library "/usr/pgsql-11/lib/oracle_fdw.so": libclntsh.so.19.1: cannot open shared object file: No such file or directory". Yes, it returned in the list by this command.
AlexDevLer commented Sep 24, 2019
I have found the directory to which i should include this file, /usr/lib64. I included libclntsh.so, libnnz19.so and libclntshcore.so.19.1, after that i have an error "ERROR: could not load library "/usr/pgsql-11/lib/oracle_fdw.so": /usr/pgsql-11/lib/oracle_fdw.so: undefined symbol: errcontext
". I think that something is going wrong, but i dont know what.
AlexDevLer commented Sep 24, 2019
laurenz commented Sep 24, 2019 •
Yes, it must be a problem similar to the one you are referring to. It is probably caused by different PostgreSQL installations on the same machine and by manually copying files around.
You should never copy any part of the PostgreSQL installation anywhere else, it is unnecessary and may cause confusion.
Also you shouldn't manually move oracle_fdw.so anywhere, make install will automatically place it in the correct directory.
Could you remove all the files you manually copied around, then build and install oracle_fdw again from scratch and copy and paste what you did here?
Also, what PostgreSQL installations are there on the machine?
AlexDevLer commented Sep 24, 2019
Also, what PostgreSQL installations are there on the machine?
Just a PostgreSQL, nothing else.
Читайте также: