lippq client library and openssl initialization: PQinitOpenSSL()
Hello! The PostgreSQL doc says that if the application code is initializing OpenSSL, it should tell PostgreSQL libpq client library that OpenSSL initialization is already done: https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE I was wondering if this is still true with OpenSSL 1.1.0+ The APIs to initialize OpenSSL are OPENSSL_init_ssl() or OPENSSL_init_crypto(). According to the OpenSSL doc, version 1.1.0 initializes itself automatically when calling other APIs ... https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_ssl.html As of version 1.1.0 OpenSSL will automatically allocate all resources that it needs so no explicit initialisation is required. Similarly it will also automatically deinitialise as required. So, is a call to PQinitOpenSSL(0, 0) still needed? I did some test with our application, and I could establish a TLS/SSL connection using server and client certificates. What can go wrong in fact? Can someone give me a hint, so I can prove that we really need to call PQinitOpenSSL(0,0)? Note: Our application is for now single-threaded. OpenSSL doc also states: However, there may be situations when explicit initialisation is desirable or needed, for example when some nondefault initialisation is required. If our application would requires nondefault initialization, I assume that PostgreSQL openssl usage will implicitly inherit the OpenSSL seetings of our application, right? Can this be an issue for PostgreSQL, or can both just share the same OpenSSL settings/config? Thanks! Seb
Re: lippq client library and openssl initialization: PQinitOpenSSL()
On Sun, Sep 11, 2022 at 6:55 AM Sebastien Flaesch wrote: > > The PostgreSQL doc says that if the application code is initializing OpenSSL, > it should tell PostgreSQL libpq client library that OpenSSL initialization is > already done: > > https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE > > I was wondering if this is still true with OpenSSL 1.1.0+ > > The APIs to initialize OpenSSL are OPENSSL_init_ssl() or > OPENSSL_init_crypto(). > > According to the OpenSSL doc, version 1.1.0 initializes itself automatically > when calling other APIs ... > > https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_ssl.html > > As of version 1.1.0 OpenSSL will automatically allocate all resources that it > needs so no explicit initialisation is required. Similarly it will also > automatically deinitialise as required. > > So, is a call to PQinitOpenSSL(0, 0) still needed? > > I did some test with our application, and I could establish a TLS/SSL > connection using server and client certificates. > > What can go wrong in fact? > > Can someone give me a hint, so I can prove that we really need to call > PQinitOpenSSL(0,0)? > > Note: Our application is for now single-threaded. > > OpenSSL doc also states: > > However, there may be situations when explicit initialisation is desirable or > needed, for example when some nondefault initialisation is required. > > If our application would requires nondefault initialization, I assume that > PostgreSQL openssl usage will implicitly inherit the OpenSSL seetings of our > application, right? > > Can this be an issue for PostgreSQL, or can both just share the same OpenSSL > settings/config? For the OpenSSL side of things, then see https://wiki.openssl.org/index.php/Library_Initialization . Jeff
Re: lippq client library and openssl initialization: PQinitOpenSSL()
Sebastien Flaesch writes: > The PostgreSQL doc says that if the application code is initializing OpenSSL, > it should tell PostgreSQL libpq client library that OpenSSL initialization is > already done: > https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE > I was wondering if this is still true with OpenSSL 1.1.0+ Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and not compiled if you built against 1.1.0. The only thing left that will happen if you don't call PQinitOpenSSL is an extra call to OPENSSL_init_ssl, which should be harmless as far as I can see from the OpenSSL docs. regards, tom lane
Re: [EXT] Re: log_min_messages = warning
Hi Steve,
I happened to see the pg_cron extensions these days, IMHO this is
not a bug, pg_cron has two kind of bg workers, one is the launcher
and the other is CronBackgroundWorker, the launcher is responsible
for scheduling the jobs, and CronBackgroundWorker is the real worker
doing the job.
See more comments inline.
On Wed, Sep 7, 2022 at 9:24 PM Dirschel, Steve
wrote:
>
> > "Dirschel, Steve" writes:
> >> setdatabase | setrole |
> >>
> >> setconfig
>
> >> -+-+--
> >> -+-+--
> >> -+-+--
> >> -+-+--
> >> -+-+--
> >>
> >>16401 | 0 | {auto_explain.log_min_duration=-1}
> >>16401 | 10 | {log_min_messages=panic}
> >>16436 | 0 | {TimeZone=America/Chicago}
> >>0 | 10 |
> >> {TimeZone=utc,log_statement=all,log_min_error_statement=debug5,log_min_messages=panic,exit_on_error=0,statement_timeout=0,role=rdsadmin,auto_explain.log_min_duration=-1,temp_file_limit=
> >> -1,"search_path=pg_catalog,
> >> public",pg_hint_plan.enable_hint=off,default_transaction_read_only=off
> >> }
> >> (4 rows)
>
> >> If I login to the shgroup02s database as postgres user (using psql)
> >> and interactively call a procedure that cron calls which causes the
> >> RAISE NOTICE commands to be written to the log they do NOT get written
> >> to the log when I call the procedure. The messages will be displayed
> >> on my screen but I don't see them getting written to the log.
>
> >You've evidently done "ALTER USER postgres SET log_min_messages=panic", so
> >the lack of any messages under that userid is unsurprising. But we're not a
> >lot closer to being sure why it's different for the procedures' normal
> >execution environment.
>
> >At this point it's hard to avoid the conclusion that those procedures'
> >session is changing the value itself. (This is scary, because it implies
> >that you're running those as superuser, which seems like a bad idea.) You
> >might have to enable log_statement = all to verify that.
>
> > regards, tom lane
>
> I appreciate your feedback Tom. To simplify this I created this procedure:
>
> create or replace procedure part.test1()
> LANGUAGE plpgsql
> AS $$
> DECLARE
>
> BEGIN
>
> raise notice '* raise notice test *';
>
> END $$;
>
> If I call that through PSQL this is returned to my screen:
>
> shgroup02s=> call part.test1();
> NOTICE: * raise notice test *
> CALL
>
> And if I monitor the log file nothing is written to it. But if I schedule
> that procedure through pg_cron:
>
> SELECT cron.schedule('Minute test', '* * * * *', 'call part.test1()');
>
> If I monitor the log file I see it writing this to the log- it actually
> writes it out 2 times:
>
> 2022-09-07 12:54:33 UTC::@:[21535]:LOG: cron job 6: NOTICE: * raise
> notice test *
> CONTEXT: PL/pgSQL function part.test1() line 6 at RAISE
> 2022-09-07 12:54:33 UTC::@:[21535]:LOG: cron job 6: NOTICE: * raise
> notice test *
> CONTEXT: PL/pgSQL function part.test1() line 6 at RAISE
>
The above logs are printed by the launcher, it collects the result
from a finished job, and as we can
see, it's a *LOG* level log, the *NOTICE* here is just part of the message.
The bg worker doing the real job doesn't put any log into the logfile,
there is a
*cron.log_min_messages* which you can set to *NOTICE* in postgresql.conf,
and then you can see the *NOTICE* log in the logfile.
Another thing that should be make clear is, the *LOG* level seems always
get printed into the log file due to the logic of `is_log_level_output`:
```
static inline bool
is_log_level_output(int elevel, int log_min_level)
{
if (elevel == LOG || elevel == LOG_SERVER_ONLY)
{
if (log_min_level == LOG || log_min_level <= ERROR)
return true;
}
```
You can also set *cron.log_min_messages* to *fatal* or *panic* to get rid of
the launcher's *LOG* level log.
> If I create another test procedure:
>
> create or replace procedure part.test2()
> LANGUAGE plpgsql
> AS $$
> DECLARE
>
> BEGIN
>
> raise exception '* raise ERROR test *';
>
> END $$;
>
> When I execute that through PSQL this is returned:
>
> shgroup02s=> call part.test2();
> ERROR: * raise ERROR test *
>
> And in the log file I see this written:
>
> 2022-09-07 12:58:00
> UTC:10.210.119.217(42434):postgres@shgroup02s:[15409]:ERROR: * raise
> ERROR test *
> 2022-09-07 12:58:00
> UTC:10.210.119.217(42434):postgres@shgroup02s:[15409]:CONTEXT: PL/pgSQL
> function
Re: lippq client library and openssl initialization: PQinitOpenSSL()
> On 11 Sep 2022, at 17:08, Tom Lane wrote: > > Sebastien Flaesch writes: >> The PostgreSQL doc says that if the application code is initializing >> OpenSSL, it should tell PostgreSQL libpq client library that OpenSSL >> initialization is already done: >> https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE >> I was wondering if this is still true with OpenSSL 1.1.0+ > > Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and > not compiled if you built against 1.1.0. The only thing left that > will happen if you don't call PQinitOpenSSL is an extra call to > OPENSSL_init_ssl, which should be harmless as far as I can see > from the OpenSSL docs. To the best of my knowledge, thats entirely correct. -- Daniel Gustafsson https://vmware.com/
Re: lippq client library and openssl initialization: PQinitOpenSSL()
Daniel Gustafsson writes: > On 11 Sep 2022, at 17:08, Tom Lane wrote: >> Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and >> not compiled if you built against 1.1.0. The only thing left that >> will happen if you don't call PQinitOpenSSL is an extra call to >> OPENSSL_init_ssl, which should be harmless as far as I can see >> from the OpenSSL docs. > To the best of my knowledge, thats entirely correct. Should we document these functions as obsolete when using OpenSSL >= 1.1.0 ? regards, tom lane
Re: lippq client library and openssl initialization: PQinitOpenSSL()
> On 11 Sep 2022, at 23:35, Tom Lane wrote: > > Daniel Gustafsson writes: >> On 11 Sep 2022, at 17:08, Tom Lane wrote: >>> Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and >>> not compiled if you built against 1.1.0. The only thing left that >>> will happen if you don't call PQinitOpenSSL is an extra call to >>> OPENSSL_init_ssl, which should be harmless as far as I can see >>> from the OpenSSL docs. > >> To the best of my knowledge, thats entirely correct. > > Should we document these functions as obsolete when using > OpenSSL >= 1.1.0 ? Given that 1.1.0+ is very common, it's probably not a bad idea to document them as obsolete but harmless. Unless you beat me to it I can propose a patch. -- Daniel Gustafsson https://vmware.com/
