Andrew Chernow wrote:
Rainer Bauer wrote:
"Matthew T. O'Connor" wrote:
Tom Lane wrote:
ROTFL ... so to translate: "If your program crashes, please release
locks before crashing."
Obviously that wasn't the intent of the above, but I guess it is the
net effect. Either way, I don't think it's a huge problem, it just
means that PG may not be able to restart for a few seconds until the
OS has time to clean-up the locks.
I don't think so. I am using DevStudio 2005 here and from time to
time the
debugger crashes so that I have to kill the program via the task
manager.
Afterwards it's not possible to load the crashed project again in a
newly
started DevStudio session, because some project files are still locked
exclusively. The only action that helps is rebooting windows.
Now, I don't know whether DevStudio is using LockFileEx() but somehow
this
sounds familiar.
Rainer
Has anyone considered not using a file lock on windows? CreateMutex
might do the trick if provided a mutex name, making it global rather
than process bound. OpenMutex can be used to test if the mutex exists
or if it is currently locked. I guess it would stay locked. If there
is a crash, it is automatically closed by the os.
The docs state the system closes the handle (mutex) when the process
terminates and makes no mention of this being a lingering action like
LockFileEx. It sounds like the mutex is closed ASAP when the process
terminates, just like file handles.
Please review the previous discussion. This whole thing came about
because of major problems in handling Global objects.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
