Jump to content

PostgreSQL Library


Recommended Posts

  • 1 month later...

I've just pushed new branch to Dr Powell's repo, and built a new version of this package.

I used LabVIEW 2017 SP1.

What's new :

  • added support for Linux Rt targets (possibly Linux in general but not tested) (issue #1)
  • added support for boolean parameter (issue #2)
  • fix a weakness in parameter detection (issue #3)

VIP 0.2.2-b16 can be downloaded from here.

  • Like 1
Link to comment
On 1/21/2021 at 1:44 PM, ShaunR said:

It depends how it is compiled.

There seems to be a function to determine whether the binary is thread safe, yielding 1 if it is and zero if it isn't.



int PQisthreadsafe();

Source

Running on Linux RT with the libpq.so compiled by NI : so they did build the library as thread safe

and I get the same on Windows with the libpq dll deployed with the VIP.

image.png.a28d33a9535794cbc9ccd2042b58d6c0.png

Edited by Antoine Chalons
Link to comment

I've opened a support request with NI because on NI Linux RT, calling libpq.so with a threadsafe CLFN crashes LabVIEW while calling it with a non-threadsafe CLFN works fine.

Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

Link to comment
2 hours ago, Antoine Chalons said:

I've opened a support request with NI because on NI Linux RT, calling libpq.so with a threadsafe CLFN crashes LabVIEW while calling it with a non-threadsafe CLFN works fine.

Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

What do you mean with "threadsafe CLN"? It is a rather bogus terminology in this context.

What you have is "reentrant" which requires the library to be multithreading safe and "UI Thread", which will allow the library to do all kind of non multithreading safe things. That trying to call PGisthreadsafe() from any context is not crashing is to be expected. This function simply accesses a readonly information that was created at compile time and put in the library. There is absolutely nothing that could potentially cause threading issues in that function. That every other function simply crashes even if you observe proper data flow dependency so that functions never can attempt to access the same information at the same time, would be utterly strange. That would not be just the reentrant setting causing multithreading unsafe issues but something much more serious and basic.

I at least assume that you tried this also in single stepping highlighting mode? Does it still crash then?

Edited by Rolf Kalbermatter
Link to comment
3 hours ago, Antoine Chalons said:

Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.

That's because it's hard-coded to return a simple Boolean when compiled.

int
PQisthreadsafe(void)
{
#ifdef ENABLE_THREAD_SAFETY
    return true;
#else
    return false;
#endif
}

 

  • Confused 1
Link to comment
23 hours ago, Rolf Kalbermatter said:

What do you mean with "threadsafe CLN"? It is a rather bogus terminology in this context.

What you have is "reentrant" which requires the library to be multithreading safe and "UI Thread", which will allow the library to do all kind of non multithreading safe things. That trying to call PGisthreadsafe() from any context is not crashing is to be expected. This function simply accesses a readonly information that was created at compile time and put in the library. There is absolutely nothing that could potentially cause threading issues in that function. That every other function simply crashes even if you observe proper data flow dependency so that functions never can attempt to access the same information at the same time, would be utterly strange. That would not be just the reentrant setting causing multithreading unsafe issues but something much more serious and basic.

I at least assume that you tried this also in single stepping highlighting mode? Does it still crash then?

Sorry for the lack of clarity, what I meant by threadsafe CLFN is this : image.png.d6b373ebf2433629ff91419e079c00ee.png therefore : reentrant

As opposed to non-threadsafe CLFN : image.png.1dfe46978bd1cee1e897f1e6e368df06.png therefore : not reentrant.

In my applications I don't need reentrancy for my libpq calls, but as I was trying to make this package as generic as possible.

Yes I've tested step by step and running the same simple thing : PQconnect / PQfinish crashes when CLFNs are reentrant, not at the PQconnect though, at the PQfinish.

The data base that I try to access does exist and the settings in the string are correct.

The result is the same wether this VI is set as reentrant or not.

image.png.d97ea32e4d2233209885155547625db4.png

22 hours ago, ShaunR said:

That's because it's hard-coded to return a simple Boolean when compiled.


int
PQisthreadsafe(void)
{
#ifdef ENABLE_THREAD_SAFETY
    return true;
#else
    return false;
#endif
}

 

Ok, I'm fealing cheated. If I understand correctly it means NI's libpq.so pretends to be threadsafe but actually isn't.

Link to comment
43 minutes ago, Antoine Chalons said:

Ok, I'm fealing cheated. If I understand correctly it means NI's libpq.so pretends to be threadsafe but actually isn't.

Actually not exactly. NI set this compile define to make the shared library multi-threading safe, trusting the library developers to have done everything correctly to get this work like it should but somehow it doesn't. Still there is something seriously odd.

I could understand that things get nasty if you had other code running in the background also accessing this library at the time you do this test but if this is the only code accessing this shared library something is definitely odd. There is still only one call to the shared library at the time your PQfinish() executes so the actual protection from multiple threads accessing this library is really irrelevant.

So how did you happen to configure the PGconn "handle"? Is this a pointer sized integer variable? You are executing on an IC-7173 which is a Linux x64 target, so these "handles" are 64-bit big on your target but 32-bit if you execute the code on LabVIEW for Windows 32-bit! I'm just throwing out ideas here, but the crash from just calling one single function of a library in a reentrant CLN really doesn't make to much sense. The only other thing that could be relevant is if this library would use thread-local storage, but that would be brain damaged considering that it uses "handles" for its connections and can therefore store everything relevant in there instead.

And a warning anyways: While I doubt that you would find PG libraries that are not compiled as multithreading safe (this only really makes sense on targets that provide no proper threading support such as Windows threading or the Unix pthread system) there obviously is a chance that it could happen. You can choose to implement everything reentrant and on creation of a new connection, call the function that Shaun showed you. But what then? If that function returns false, all you can do is abort and return an error as you can not dynamically reconfigure the CLNs to use UI threading instead (well you can by using scripting but I doubt you want to do that on every connection establishment and scripting is also not available in a built application). So it does make your library potentially unusable if someone uses a binary shared library compiled to be not multithreading safe.

Edited by Rolf Kalbermatter
Link to comment
  • 1 year later...
  • 4 months later...

I couldn't find the code repository entry for this library, but I am getting an error: 

PQ Connection.lvclass:Connect.vitsdb CONNECTION_BAD: authentication method 10 not supported

with postgres versions 14.7 on linux, and 15.2 on pc, running the toolkit in LV2021 on windows.

Is there an issue with the authentication and SHA-256 on the newer versions of postgres?

Link to comment

Hi @Jordan Kuehn I recently had the same issue with not being able to use SHA-256 passwords. I had to change them in my database to md5. I think James is right that the library needs to be updated to support SHA-256. See also here: https://www.vipm.io/posts/6b996996-5212-4191-aef4-ccaf68c93ae7/ (Perhaps someone can recruit Tom to help us out?)

@drjdpowell Can you give me pull or commit access to the repository and I can help coordinate fixing this and other issues?

 

Patrick

 

 

Link to comment
  • 6 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.