We currently have a patch sitting in the queue from Tsutomu Yamada with modifications from me, all based on an idea from Trevor Talbot some time back. (That should do it for credits) It tries to pre-reserve the shared memory region during DLL initialization, and then releases it just in time to reallocate it as shared memory. (that will do for technical detail for now) This should hopefully fix the infamous "failed to re-attach to shared memory" errors we've been seeing on Windows.
We need your help to test it!
We need help both from people who are experiencing the problem - to see if it solves it, and from people who are not experiencing it - to make sure it doesn't cause any new problems.
Dave has built binaries for 8.3.7 and 8.4.0. To test the patch, stop your server, take a backup copy of your postgres.exe file, and replace it with the file from the appropriate ZIP file before. Restart the server, and see if it works!
Once you have tested, please report your success to the pgsql-hackers list, or directly to me and I'll tally it up.
Update: These patched binaries will only work if you installed from the One-click installer. Specifically, they will not work if you installed from the MSI installer due to a mismatch in the configuration option for integer vs floating point datetime handling.
I've "installed" the 8.3.7 patch today and will give you a feedback as soon as possible. greetings from berlin -stefan wolf-
Failed on 8.3.7. :(
The system log says that the cluster has been initialized without and the server has been compiled with HAVE_INT64_TIMESTAMP.
2009-07-27 10:55:49 CEST u: db: tr:0 FATAL: Datenbankdateien sind inkompatibel mit Server 2009-07-27 10:55:49 CEST u: db: tr:0 DETAIL: Der Datenbank-Cluster wurde ohne HAVE_INT64_TIMESTAMP initialisiert, aber der Server wurde mit HAE_INT64_TIMESTAMP kompiliert. 2009-07-27 10:55:49 CEST u: db: tr:0 TIPP: Es sieht so aus, dass Sie neu kompilieren oder initdb ausführen müssen.
The cluster has been initialized manually (in order to support LATIN1) with:
initdb --locale=German_Germany.28591 -W -A md5 -D "C:\Programme\PostgreSQL\8.3\data"
Oh, crap. Ok, the reason for that - it's built with the same parameters as the on-click installer, but I bet you installed from the MSI...
Yes - it's an install from the MSI-version.
Ok, I'm afraid we currently don't have any patched binaries available for that one as they were built by the same buildfarm that builds the oneclick installers.
I've deployed the 8.4.0 binary on my development machine. No issues until now (nor there were before btw).
Tested it on Windows 7 using PG 8.4 and everything seems to work fine (I've done only a very short test: starting the server and creating a table).
Hope this helps.
Thanks for testing!
One good thing to test would be to simply connect and disconnect a number of times - that's when the issue usually show up. Or perhaps run pg_bench on it (don't care about the numbers or anything, but it will run a bunch of queries over some time).
I've also ran pgbench and everything seems fine (it ran without errors).
I did test for one day (Windows Vista). There is no error message anymore.
This is the second day with the 8.3.7 patch - and this is my first errormessage:
ERROR: cout not stat file "base/17182/18677": Permission denied
I closed the connection (pgAdmin III 1.8.4) and re-connected without errors.
Will binaries be a provided for those that install using the MSI Installer? Would love to test this patch as this bug has been a huge problem for us. Thanks for any help.
No, if you need the installer you need to wait until the next minor version release. This is expected out within a couple of weeks though, so the wait won't be too long.
Oooo, can't wait to try this out! I've been getting hundreds of those errors on Windows Server 2008 with both 8.3.7 and 8.4.
Is this still available for 8.4 and does it work. A production server started getting this error last week after a Windows update, And I'm hoping this will fix it! the link to the 8.4 file is broken...
First, forgiving my English. I translated it with google.
And now my question, this patch really work? I need to solve this problem in 25 installations of postgres. The links doesn't work, could you provide me the patch?
Thank you very much.
This patch has been included in all supported versions of PostgreSQL. Do you not need a separate patch.
Thanks for your reply!
My postgres version is 8.3. Greater version resolve my problem?
8.3 is a supported version, so it is already solved. According to the release notes, you need 8.3.8 or newer (http://www.postgresql.org/docs/8.3/static/release-8-3-8.html). Obviously, you should be on 8.3.15 if you are using 8.3.