Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

2018-10-12 Thread magodo
On Thu, 2018-10-11 at 19:53 +0200, Laurenz Albe wrote:

> Indeed, your sentence
> 
> > if , for example, it recovered to "A" at "o1", then
> > the switched WAL(in case of stop-then-recover) or .partial
> > corresponding WAL(in case of promote) is the last WAL of the
> > timeline1
> 
> seems to contradict your drawing, which has B after A on timeline 1.

Err... I mean "o1" is the end of timelien1, and the last WAL is the one
"o1" was on just before recovering to "A".


> Example:
> Assume that timeline 1 reaches to 000100150030.
> We recover to point A, which is in the middle of
> 000100150020,
> and there branch to timeline 2.
> After some time, we decide to recover again, starting from a
> checkpoint in 000100150010.
> We want to recover to 2018-10-11 12:00:00.
> 
> How can you know how many WAL segments there are on timeline 1, and
> if
> there is one that extends past 2018-10-11 12:00:00 or not?

This is the exact problem I want to figure out. My approach is as you
said, I will parse each archived WAL segment via `pg_xlogdump -r
Transaction`, and try to find the first least earliest WAL against the
specified time. This is a linear search, which has complexity of O(n). 


So if you want to recover to that point of time, how do you choose the
timeline?

---
Magodo


Re: Want to acquire lock on tables where primary of one table is foreign key on othere

2018-10-12 Thread Abhishek Tripathi
Thank you for your response.

I am explaining my situation there is table A on which I have taken a row
lock and the primary key of table A is related with table B as a foreign
key so automatically I can not insert new row with that  foreign key  now
the primary key of table B is used as foreign key in table C and insertion
can be done on table C. I just want to lock table C also No insertion can
be done on table C related to table B primary key.



On Thu, Oct 11, 2018 at 8:26 PM Alban Hertroys  wrote:

> On Thu, 11 Oct 2018 at 16:38, Abhishek Tripathi
>  wrote:
> > Actually I have acquired a "Select for Update" on a table whose id is
> refrence as a foreign key on another table So I want those table won't
> update until there is lock. Is it possible? Becuase postgres is acquiring
> lock but AccessShare Lock which allow to write on those table How I
> restrict this.
>
> For what purpose do you want that? What is inadequate about the lock
> that Postgres acquires?
>
> Table locks are very rarely what you want, as it blocks all concurrent
> access to the entire table, while that is only necessary for a few
> rarely used corner cases; a foreign key update is not among those.
>
> --
> If you can't see the forest for the trees,
> Cut the trees and you'll see there is no forest.
>


Re: Advice on logging strategy

2018-10-12 Thread David Steele

On 10/11/18 11:26 AM, Mike Martin wrote:


This results in enormous log files which take ages to import using copy 
becuase each execute statement is logged with the parameters chosen


Is there any way around this?

I cant find any way to filter dml statements


pgAudit (https://github.com/pgaudit/pgaudit) gives you fine-grain 
control over what is logged by command type, table, or user as well as a 
lot more detail.


--
-David
da...@pgmasters.net



Re: RHEL 7 (systemd) reboot

2018-10-12 Thread Adrian Klaver

On 10/11/18 10:43 AM, Bryce Pepper wrote:

I disabled and removed the CTM_Postgre.service as it didn't help (and I didn't 
want too many moving parts left out there).

I did find a post 
https://superuser.com/questions/1016827/how-do-i-run-a-script-before-everything-else-on-shutdown-with-systemd
 that I think is getting me closer.

I triedRequiresMountsFor=/data00which starts the script much sooner but 
unfortunately  the  postgresql instance is unreachable by the time the script 
gets there.


Seems to me the first priority is finding what is shutting down Postgres.

Does the system log show anything?

If not, find the shutdown time in the Postgres log and correlate that 
with the system log.




These are two unique datacenter shutdowns: ctmdist  & ctmlinux

Oct 11 09:20:00 kccontrolmt01 stop_ctmdist_server.sh[10316]: setenv: Too many 
arguments.
Oct 11 09:20:00 kccontrolmt01 stop_ctmdist_server.sh[10316]: Stopping CONTROL-M 
application Oct 11 09:20:00 kccontrolmt01 stop_ctmdist_server.sh[10316]: SQL 
Server is not running.
Oct 11 09:20:00 kccontrolmt01 stop_ctmlinux_server.sh[10318]: setenv:
Too many arguments.
Oct 11 09:20:00 kccontrolmt01 stop_ctmlinux_server.sh[10318]: Stopping 
CONTROL-M application Oct 11 09:20:00 kccontrolmt01 
stop_ctmlinux_server.sh[10318]: SQL Server is not running.




--
Adrian Klaver
adrian.kla...@aklaver.com



Re: Advice on logging strategy

2018-10-12 Thread Mike Martin
Thanks!

On Fri, 12 Oct 2018 at 14:33, David Steele  wrote:

> On 10/11/18 11:26 AM, Mike Martin wrote:
> >
> > This results in enormous log files which take ages to import using copy
> > becuase each execute statement is logged with the parameters chosen
> >
> > Is there any way around this?
> >
> > I cant find any way to filter dml statements
>
> pgAudit (https://github.com/pgaudit/pgaudit) gives you fine-grain
> control over what is logged by command type, table, or user as well as a
> lot more detail.
>
> --
> -David
> da...@pgmasters.net
>


Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Ádám Maracska
Hi,

Currently I am trying to compile my pqlib with SSL version 1.1.0, but I get
the following errors:

*fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies undefined
struct/union 'bio_st'*
*fe-secure-openssl.c(1582): error C2198: 'pqsecure_raw_read': too few
arguments for call*
*fe-secure-openssl.c(1612): error C2037: left of 'ptr' specifies undefined
struct/union 'bio_st'*
*fe-secure-openssl.c(1612): error C2198: 'pqsecure_raw_write': too few
arguments for call*
*fe-secure-openssl.c(1670): error C2027: use of undefined type
'bio_method_st'*
*fe-secure-openssl.c(1673): error C2027: use of undefined type
'bio_method_st'*
*fe-secure-openssl.c(1674): error C2037: left of 'bread' specifies
undefined struct/union 'bio_method_st'*
*fe-secure-openssl.c(1675): error C2037: left of 'bwrite' specifies
undefined struct/union 'bio_method_st'*
*fe-secure-openssl.c(1701): error C2037: left of 'ptr' specifies undefined
struct/union 'bio_st'*

As I was checking the issue on google I found the following two message
thread about it:

- From 2016: Based on this the ssl version 1.1 is supported, but the
message thread had not so promising end:
https://www.postgresql.org/message-id/flat/E1bkVG3-L8-Ln%40gemulon.postgresql.org
- From 2018: It had even more worse end. The questioner went back to 1.0.2
ssl version, which is not an option for me, because that version will not
be supported shortly by openssl itself.
https://www.postgresql.org/message-id/CAAw-Mseg9JYpp%3DA%3D51HR3rKiQtbvT0MWw%2BaYFwNeJEbdNr%3DCDA%40mail.gmail.com

Also I checked the source files and I saw these kind of comments:
* They are also not needed with OpenSSL 1.1.0 anymore.
(fe-secure-openssl.c)*

I suppose it is possible to compile the pqlib with ssl 1.1, but I can not
wrap my head around it. Maybe I should set some ifdefs for the
precompiler beforehand?

I appreciate any help.

Best Regards,
Adam


Re: Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Adrian Klaver

On 10/12/18 7:15 AM, Ádám Maracska wrote:

Hi,

Currently I am trying to compile my pqlib with SSL version 1.1.0, but I 
get the following errors:

/
/
/fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies 
undefined struct/union 'bio_st'/
/fe-secure-openssl.c(1582): error C2198: 'pqsecure_raw_read': too few 
arguments for call/
/fe-secure-openssl.c(1612): error C2037: left of 'ptr' specifies 
undefined struct/union 'bio_st'/
/fe-secure-openssl.c(1612): error C2198: 'pqsecure_raw_write': too few 
arguments for call/
/fe-secure-openssl.c(1670): error C2027: use of undefined type 
'bio_method_st'/
/fe-secure-openssl.c(1673): error C2027: use of undefined type 
'bio_method_st'/
/fe-secure-openssl.c(1674): error C2037: left of 'bread' specifies 
undefined struct/union 'bio_method_st'/
/fe-secure-openssl.c(1675): error C2037: left of 'bwrite' specifies 
undefined struct/union 'bio_method_st'/
/fe-secure-openssl.c(1701): error C2037: left of 'ptr' specifies 
undefined struct/union 'bio_st'/


As I was checking the issue on google I found the following two message 
thread about it:


- From 2016: Based on this the ssl version 1.1 is supported, but the 
message thread had not so promising end: 
https://www.postgresql.org/message-id/flat/E1bkVG3-L8-Ln%40gemulon.postgresql.org
- From 2018: It had even more worse end. The questioner went back to 
1.0.2 ssl version, which is not an option for me, because that version 
will not be supported shortly by openssl itself. 
https://www.postgresql.org/message-id/CAAw-Mseg9JYpp%3DA%3D51HR3rKiQtbvT0MWw%2BaYFwNeJEbdNr%3DCDA%40mail.gmail.com


Also I checked the source files and I saw these kind of comments:
/ They are also not needed with OpenSSL 1.1.0 anymore. 
(fe-secure-openssl.c)/

/
/
I suppose it is possible to compile the pqlib with ssl 1.1, but I can 
not wrap my head around it. Maybe I should set some ifdefs for the 
precompiler beforehand?


I appreciate any help.


What OS and version of same are you compiling in?

Do you have the SSL dev libraries installed?



Best Regards,
Adam



--
Adrian Klaver
adrian.kla...@aklaver.com



Re: Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Tom Lane
=?UTF-8?B?w4Fkw6FtIE1hcmFjc2th?=  writes:
> Currently I am trying to compile my pqlib with SSL version 1.1.0, but I get
> the following errors:
> *fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies undefined
> struct/union 'bio_st'*
> [etc]

That certainly ought to work, and does work for me and for several of
our buildfarm machines.  I suspect you messed up the build somehow;
perhaps you changed OpenSSL versions and didn't re-run configure?  Or
the OpenSSL headers you have installed don't match the library version?
Are the errors you showed the *only* ones you get?

regards, tom lane



Re: Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Pratik Parikh
I have seen the same failure on windows build.  I can only use
openssl 1.02(x).

On Fri, Oct 12, 2018 at 11:32 AM Tom Lane  wrote:

> =?UTF-8?B?w4Fkw6FtIE1hcmFjc2th?=  writes:
> > Currently I am trying to compile my pqlib with SSL version 1.1.0, but I
> get
> > the following errors:
> > *fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies
> undefined
> > struct/union 'bio_st'*
> > [etc]
>
> That certainly ought to work, and does work for me and for several of
> our buildfarm machines.  I suspect you messed up the build somehow;
> perhaps you changed OpenSSL versions and didn't re-run configure?  Or
> the OpenSSL headers you have installed don't match the library version?
> Are the errors you showed the *only* ones you get?
>
> regards, tom lane
>
>

-- 
Pratik Parikh
- Mantra - Keep It Simple and Straightforward


French translation of CoC

2018-10-12 Thread Lætitia Avrot
Hi,

You'll find enclosed a french translation (reviewed by the community on the
french mailing-list) of the Code Of Conduct.

Regards,

Lætitia

-- 
*Think! Do you really need to print this email ? *
*There is no Planet B.*
# Introduction

Le projet PostgreSQL est fier de la qualité de son code, de son travail et des
résultats professionnels de sa communauté. Nous attendons de chaque
participant qu'il se conduise de manière professionnelle, en agissant
avec courtoisie dans l'intérêt commun, tout en respectant tous les utilisateurs
et les développeurs.

Dans ce but, nous avons mis en place un Code de Conduite pour les échanges
avec la communauté, la participation au travail du projet et la communauté en
général. Ce Code a pour but de couvrir toutes les interactions entre les
membres de la communauté, que ces échanges aient lieu au sein de
l'infrastructure postgresql.org ou pas, du moment qu'il n'y a pas d'autre Code
de Conduite qui puisse s'appliquer (comme le Code de Conduite d'une conférence
par exemple).

# Inclusivité et conduite appropriée

Le projet PostgreSQL est ouvert à la participation de chaque personne souhaitant
travailler avec PostgreSQL, quel que soit son niveau d'expérience sur ce
logiciel ou sur la technologie en général. Nous encourageons le développement et
les contributions de tous les utilisateurs, quelle que soit leur histoire.

Nous encourageons des discussions constructives et réfléchies sur le logiciel,
cette communauté, leur état actuel respectif et leurs possibles futurs
développements. Les discussions devraient être centrées sur le code, les
technologies liées, les projets de la communauté ou l'infrastructure.

Les attaques personnelles et les commentaires négatifs sur les
caractéristiques d'une personne ne sont pas acceptables et ne seront pas
acceptés. Les caractéristiques d'une personne peuvent inclure (mais ne
sont pas limitées à) l'âge, l'origine ethnique, la nationalité d'origine ou les ancêtres,
la religion, le genre ou l'orientation sexuelle.

De plus, les attitudes qui sont aussi en violation de ce code de conduite
comprennent (mais ne se limitent pas à) les menaces de violence contre une
personne ou un groupe de personnes, les menaces de sabotage de vie
professionnelle, de communauté et/ou de projet, les sollicitations sexuelles non
souhaitées, quelles que soient leurs formes, les attitudes qui pourraient porter
préjudice au projet PostgreSQL et le refus de cesser cette conduite
inappropriée malgré une demande en ce sens.

# Protection des plaignants

Il est également expressément interdit à quiconque d'exercer des représailles contre
une personne ayant déposé une plainte pour violation de ce Code de Conduite ou
contre une personne assistant le comité lors de l'enquête suite à un signalement.
Seront considérées comme des représailles (entre autres) les actions suivantes:

* de nouvelles attaques personnelles (publiques ou privées) ;
* des actions ayant pour but d'affaiblir le statut professionnel d'une personne que ce soit en public ou vis-à-vis de son employeur, ses collègues, ses clients ou la communauté ;
* des actions qui menacent la vie privée, l'intégrité physique, le bien-être, le foyer et/ou la famille d'une personne.

Les actes de représailles seront traités de la même manière que n'importe quelle
autre violation de ce Code de Conduite.

# Comité du Code de Conduite

La Core Team désignera un Comité du Code de Conduite pour recevoir et enquêter
sur toutes les plaintes ainsi qu'une présidence de ce comité. N'importe quel
membre de la communauté peut être candidat à ce comité, à l'exception des
membres de la Core Team. Comme la Core Team supervise le Comité, les membres de
la Core Team ne pourront pas être également membres du Comité, pour éviter les
conflits d'intérêt. La liste des membres du Comité sera publiée et toujours
disponible [ici](https://www.postgresql.org/about/policies/coc_committee/).

Les membres seront renouvelés tous les ans. La Core Team annoncera les dates
d'ouverture et de fermeture de la sélection des candidats sur les canaux de
communication habituels. Tout membre de la communauté qui souhaiterait être
candidat répondra à une première série de questions. Les réponses seront
évaluées par la Core Team et les membres du comité actuel pour sélectionner
les candidats et mener des entretiens avec chacun d'entre eux. Le Comité
actuel fera des recommandations et la Core Team choisira les nouveaux membres du
Comité.

Le nombre de membres du Comité n'est pas défini, cependant, il faudra qu'il soit
constitué d'un minimum de quatre (4) personnes. Les membres du Comité s'engagent pour un
minimum d'un an. Ils peuvent rester membres de ce Comité plus longtemps s'ils
le souhaitent, avec un maximum de trois (3) ans.

Les membres du Comité agissent suivant la volonté de la Core Team et la Core
Team peut relever un membre de ses fonctions si elle pense que ce membre ne peut
plus assumer ses responsabilités.

Le Comité peut aussi de sa propre initiative deman

Re: Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Tom Lane
Pratik Parikh  writes:
> I have seen the same failure on windows build.  I can only use
> openssl 1.02(x).

Hmm ... looking at it closer, I realize that part of the problem is
that with 1.1.0 you need HAVE_BIO_METH_NEW to be defined, and there's
no mechanism for doing that in the MSVC build code.  Worse, there's
half a dozen other OpenSSL-version-dependent symbols that get set by
configure in non-Windows builds, but we have nothing equivalent to
that for Windows.  Michael P. laid out the situation in a recent commit
message:


Author: Michael Paquier 
Branch: master Release: REL_11_BR [bde64eb61] 2018-06-19 09:00:33 +0900

Track new configure flags introduced for version 11 in pg_config.h.win32

The following set of flags mainly matter when building Postgres code
with MSVC and those have been forgotten with latest developments:
- HAVE_LDAP_INITIALIZE, added by 35c0754f, and marked as disabled.
ldap_initialize() is a non-standard extension that provides a way to use
"ldaps" with OpenLDAP, but it is not supported on Windows, and instead
the non-standard ldap_sslinit() is used if WIN32 is defined.  Per input
from Thomas Munro.
- HAVE_X509_GET_SIGNATURE_NID, added by 054e8c6c, which is used by
SCRAM's channel binding tls-server-end-point.  Having this flag disabled
would cause this channel binding type to be unsupported for Windows
builds.
- HAVE_SSL_CLEAR_OPTIONS, added recently as of a364dfa4 to disable SSL
compression.
- HAVE_ASN1_STRING_GET0_DATA, added by 5c6df67, which is used to track
a new compatibility with OpenSSL 1.1.0.  This was missing from
pg_config.win32.h and is not enabled by default.  HAVE_BIO_GET_DATA,
HAVE_OPENSSL_INIT_SSL and HAVE_BIO_METH_NEW gain the same treatment.

The second and third flags are enabled with this commit, which raises
the bar of OpenSSL support to 1.0.2 on Windows as a minimum.  As this
is the LTS (long-time support) version of OpenSSL community and knowing
that all recent installers referred by OpenSSL upstream don't have
anymore 1.0.1 or older, we could live with that requirement.  In order
to allow the code to compile with OpenSSL 1.1.0, all the flags mentioned
above need to be enabled in pg_config.h.win32.

Author: Michael Paquier
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/20180529211559.gf6...@paquier.xyz


So the immediate fix for building on Windows is you need to manually
define all of those in pg_config.h.  We probably ought to try to make
that less painful, though.  At the very least it'd be good if there
were just one symbol you had to set manually ...

regards, tom lane



Re: Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Pratik Parikh
Thanks for providing the insight needed to make this work on Windows.

On Fri, Oct 12, 2018, 12:17 PM Tom Lane  wrote:

> Pratik Parikh  writes:
> > I have seen the same failure on windows build.  I can only use
> > openssl 1.02(x).
>
> Hmm ... looking at it closer, I realize that part of the problem is
> that with 1.1.0 you need HAVE_BIO_METH_NEW to be defined, and there's
> no mechanism for doing that in the MSVC build code.  Worse, there's
> half a dozen other OpenSSL-version-dependent symbols that get set by
> configure in non-Windows builds, but we have nothing equivalent to
> that for Windows.  Michael P. laid out the situation in a recent commit
> message:
>
>
> Author: Michael Paquier 
> Branch: master Release: REL_11_BR [bde64eb61] 2018-06-19 09:00:33 +0900
>
> Track new configure flags introduced for version 11 in
> pg_config.h.win32
>
> The following set of flags mainly matter when building Postgres code
> with MSVC and those have been forgotten with latest developments:
> - HAVE_LDAP_INITIALIZE, added by 35c0754f, and marked as disabled.
> ldap_initialize() is a non-standard extension that provides a way to
> use
> "ldaps" with OpenLDAP, but it is not supported on Windows, and instead
> the non-standard ldap_sslinit() is used if WIN32 is defined.  Per input
> from Thomas Munro.
> - HAVE_X509_GET_SIGNATURE_NID, added by 054e8c6c, which is used by
> SCRAM's channel binding tls-server-end-point.  Having this flag
> disabled
> would cause this channel binding type to be unsupported for Windows
> builds.
> - HAVE_SSL_CLEAR_OPTIONS, added recently as of a364dfa4 to disable SSL
> compression.
> - HAVE_ASN1_STRING_GET0_DATA, added by 5c6df67, which is used to track
> a new compatibility with OpenSSL 1.1.0.  This was missing from
> pg_config.win32.h and is not enabled by default.  HAVE_BIO_GET_DATA,
> HAVE_OPENSSL_INIT_SSL and HAVE_BIO_METH_NEW gain the same treatment.
>
> The second and third flags are enabled with this commit, which raises
> the bar of OpenSSL support to 1.0.2 on Windows as a minimum.  As this
> is the LTS (long-time support) version of OpenSSL community and knowing
> that all recent installers referred by OpenSSL upstream don't have
> anymore 1.0.1 or older, we could live with that requirement.  In order
> to allow the code to compile with OpenSSL 1.1.0, all the flags
> mentioned
> above need to be enabled in pg_config.h.win32.
>
> Author: Michael Paquier
> Reviewed-by: Andrew Dunstan
> Discussion: https://postgr.es/m/20180529211559.gf6...@paquier.xyz
>
>
> So the immediate fix for building on Windows is you need to manually
> define all of those in pg_config.h.  We probably ought to try to make
> that less painful, though.  At the very least it'd be good if there
> were just one symbol you had to set manually ...
>
> regards, tom lane
>


Re: Compile psql 9.6 with SSL Version 1.1.0

2018-10-12 Thread Adrian Klaver

On 10/12/18 8:06 AM, Ádám Maracska wrote:

Please reply to list also.
Ccing list.

Hi,

Thanks for the short answer and thanks for reminding me for the most 
essential details that I missed.:)


 >What OS and version of same are you compiling in?
So I would like to compile it for windows 10 x64 and with the postgresql 
9.6.5 sources.

(Later I would like to do this for debian also.)

 >Do you have the SSL dev libraries installed?
No, I do not unfortunately.

Thanks,
Adam

Adrian Klaver > ezt írta (időpont: 2018. okt. 12., 
P, 16:51):


On 10/12/18 7:15 AM, Ádám Maracska wrote:
 > Hi,
 >
 > Currently I am trying to compile my pqlib with SSL version 1.1.0,
but I
 > get the following errors:
 > /
 > /
 > /fe-secure-openssl.c(1582): error C2037: left of 'ptr' specifies
 > undefined struct/union 'bio_st'/
 > /fe-secure-openssl.c(1582): error C2198: 'pqsecure_raw_read': too
few
 > arguments for call/
 > /fe-secure-openssl.c(1612): error C2037: left of 'ptr' specifies
 > undefined struct/union 'bio_st'/
 > /fe-secure-openssl.c(1612): error C2198: 'pqsecure_raw_write':
too few
 > arguments for call/
 > /fe-secure-openssl.c(1670): error C2027: use of undefined type
 > 'bio_method_st'/
 > /fe-secure-openssl.c(1673): error C2027: use of undefined type
 > 'bio_method_st'/
 > /fe-secure-openssl.c(1674): error C2037: left of 'bread' specifies
 > undefined struct/union 'bio_method_st'/
 > /fe-secure-openssl.c(1675): error C2037: left of 'bwrite' specifies
 > undefined struct/union 'bio_method_st'/
 > /fe-secure-openssl.c(1701): error C2037: left of 'ptr' specifies
 > undefined struct/union 'bio_st'/
 >
 > As I was checking the issue on google I found the following two
message
 > thread about it:
 >
 > - From 2016: Based on this the ssl version 1.1 is supported, but the
 > message thread had not so promising end:
 >

https://www.postgresql.org/message-id/flat/E1bkVG3-L8-Ln%40gemulon.postgresql.org
 > - From 2018: It had even more worse end. The questioner went back to
 > 1.0.2 ssl version, which is not an option for me, because that
version
 > will not be supported shortly by openssl itself.
 >

https://www.postgresql.org/message-id/CAAw-Mseg9JYpp%3DA%3D51HR3rKiQtbvT0MWw%2BaYFwNeJEbdNr%3DCDA%40mail.gmail.com
 >
 > Also I checked the source files and I saw these kind of comments:
 > / They are also not needed with OpenSSL 1.1.0 anymore.
 > (fe-secure-openssl.c)/
 > /
 > /
 > I suppose it is possible to compile the pqlib with ssl 1.1, but I
can
 > not wrap my head around it. Maybe I should set some ifdefs for the
 > precompiler beforehand?
 >
 > I appreciate any help.

What OS and version of same are you compiling in?

Do you have the SSL dev libraries installed?

 >
 > Best Regards,
 > Adam


-- 
Adrian Klaver

adrian.kla...@aklaver.com 




--
Adrian Klaver
adrian.kla...@aklaver.com