PostgreSQL st_geometry errors

[ArthurChildress]

Hi, I've gotten this same error twice in the past few months.  I'm currently running ArcGIS 10.5 (recently upgraded from 10.4) on a Windows 2012R server.  I'm also connected to a feature service sourced from a PostgreSQL 9.5 (upgraded from 9.3, I think, when I upgraded ArcGIS) geodatabase (gDB) on a CentOS 7 server.  Here are the actions which caused the same error under both ArcGIS/Postgres versions: 

1. I had ArcMap open (I wasn't connected to the Postgres gDB this time; I don't remember if I was connected the last time).
2. I tried to restart the Postgres service after making a change to its pg_hba.conf, but got an error about the lock file postmaster.pid already existing.  
3. I closed ArcMap.  
4. I tried restarting Postgres again; I was successful.  
5. I reopened ArcMap and tried to connect to the Postgres gDB, but got an error (attached) about how ArcMap couldn't load the st_geometry.so file (I'd had no trouble connecting to the gDB before getting this error).  
6. On the CentOS server, I deleted then recopied the exact same st_geometry.so file from the Windows server onto the CentOS server that was in place before the error.  
7. I tried reconnecting to the gDB in ArcMap; I was successful.  

Any ideas why I get this st_geometry.so file error?  I'd restarted the Postgres successfully many times after modifying its pg_hba.conf file; thankfully this error has only happened twice so far.

[Asrujit_SenGupta]

There are no error screenshots attached to your original Post.

[VinceAngelo]

The PostgreSQL servers I work with at client sites are "frequently" restarted -- Every 4-6 weeks or so.   We're given several days' advance notice of the planned reboot during the regular after-hours outage window.  

Stopping your server before the clients can often cause "undefined behavior" on the client side, especially if the client is configured to attempt to reconnect.  

Attempting to start a server before the previous sessions exit could easily cause an error like you reported (in fact, this is the expected behavior, since the alternate is partial or complete corruption of the database instances).

Failure of the PostgreSQL monitor to access the ST_geometry.so on the server is an exceedingly bizarre situation.  I've never seen or heard of that occurring. The only possible explanation which would make sense is if the server's files are accessed through an exceedingly slow NFS mount.

In short, steps 1-4 & 7 are expected functionality, step 5 should not ever happen, and step 6 should not ever be necessary.

[ArthurChildress]

Asrujit: Sorry, here's the error

Vince: Thanks for the info.  I'm not sure how the server hardware is configured, but we haven't seen any other issues on this server that would be symptoms of a slow mount.  Then again, I'm not a sysadmin 😉

Does seeing the actual error spark any other ideas?

[VinceAngelo]

Please always include errors as text.  This allows errors to be free-text searchable (and legible on all devices).

This error seems to be a pure PostgreSQL issue, but it's probably worth talking to Tech Support about it.

Failure to read a DLL installed in the instance might be due to anti-virus or some other application which is hosing your install.

- V

[ArthurChildress]

Thanks again for the info and the tip on the error posting!