On Tue, Apr 8, 2014 at 9:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Apparently not. However, I'm fairly sure this is a step toward
> addressing the complaints previously raised, even if there may be some
> details people still want changed, so I've gone ahead and committed
> it.
Few Observations:
1. One new warning has been introduced in code.
1>src\backend\port\win32_shmem.c(295): warning C4013:
'dsm_set_control_handle' undefined; assuming extern returning int
Attached patch fixes this warning.
2. On running test_shm_mq manually, the client side didn't get
any problem (the results are as expected). However I am seeing
below log on server:
LOG: registering background worker "test_shm_mq"
LOG: starting background worker process "test_shm_mq"
LOG: unrecognized win32 error code: 127
LOG: worker process: test_shm_mq (PID 2528) exited with exit code 1
LOG: unregistering background worker "test_shm_mq"
I think below message in log is not expected:
"LOG: unrecognized win32 error code: 127"
This has been started appearing after your commit related to DSM.
I have debugged this issue and found that it comes from below part
of code:
dsm_impl_windows
{
..
else
{
hmap = OpenFileMapping(FILE_MAP_WRITE | FILE_MAP_READ,
FALSE, /* do not inherit the name */
name); /* name of mapping object */
_dosmaperr(GetLastError());
}
}
Here even though handle returned by OpenFileMapping() is a valid handle,
but still GetLastError() return 127 (The specified procedure could not be
found.). Now the specs[1] of API says that if handle is non-NULL, then
consider it success, so I am not sure whether we should bother about this
error or not. I have tried many ways (trying different parameters, search on
net) to change this and related API's, but the same problem exists. One
strange thing is if I just call the API twice (I know this is not
right, but just
to experiment for finding some info), second time this error doesn't
occur.
The only difference in latest changes is that now the OpenFileMapping()
is getting called by Child process rather than peer process (w.r.t process
that has called CreateFileMapping), don't know why this should make
such a difference.
On net whatever examples I have seen for such usage, they call
GetLastError() only if handle is invalid, we have called in above fashion
just to keep code little bit simple.
I am just not sure whether it is okay to rearrange the code and call
GetLastError() only if returned handle is Invalid (NULL) or try to look
for more info.
One question:
1. I have seen that initdb still creates pg_dynshmem, is it required
after your latest changes?
Let me know your opinion?
[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366791(v=vs.85).aspx
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com