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.
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.
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?
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.