Re: warn if GUC set to an invalid shared library

Поиск
Список
Период
Сортировка
От Cary Huang
Тема Re: warn if GUC set to an invalid shared library
Дата
Msg-id 164341298003.1123.13296936139237024875.pgcf@coridan.postgresql.org
обсуждение исходный текст
Ответ на Re: warn if GUC set to an invalid shared library  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: warn if GUC set to an invalid shared library  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           tested, passed
Documentation:            not tested

Hello

I tested the patches on master branch on Ubuntu 18.04 and regression turns out fine. I did a manual test following the
queryexamples in this email thread and I do see the warnings when I attempted: these queries:
 

postgres=# SET local_preload_libraries=xyz.so;
2022-01-28 15:11:00.592 PST [13622] WARNING:  could not access file "xyz.so"
WARNING:  could not access file "xyz.so"
SET
postgres=# ALTER SYSTEM SET shared_preload_libraries=abc.so;
2022-01-28 15:11:07.729 PST [13622] WARNING:  could not access file "$libdir/plugins/abc.so"
WARNING:  could not access file "$libdir/plugins/abc.so"
ALTER SYSTEM

This is fine as this is what these patches are aiming to provide. However, when I try to restart the server, it fails
tostart because abc.so and xyz.so do not exist. Setting the parameters "local_preload_libraries" and
"local_preload_libraries"to something else in postgresql.conf does not seem to take effect either.
 
It still complains shared_preload_libraries abc.so does not exist even though I have already set
shared_preload_librariesto something else in postgresql.conf. This seems a little strange to me 
 

thank you
Cary

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: support for MERGE
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?