Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”

I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.

On Чт, 2015-10-15 at 17:46 +0300, Dmitry Vasilyev wrote:

 I’ve created 2 unprivileged users: user1 and user2; and registered 2
services thorough pg_ctl register respectively under these 2 users.
If
first service is running second could not start and vice versa.

----
Dmitry Vasilyev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

--

----
Dmitry Vasilyev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev <d.vasilyev@postgrespro.ru>
wrote:

I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error. Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c. I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Hello,

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

It seems somewhat strange. Looking into the create operation in
dms_impl_posix(), it should return false but not emit error when
the shared memory object already exists.

So, to make the windows version behave as the same,
dsm_impl_windows should return false if GetLastError() ==
ERROR_ALREADY_EXISTS regardless of hmap is valid. The current
behavior is wrong because two or more postmaster *share* the same
DSM segment instead of having their own segments.

On the other hand, in the case of GetLastError() ==
ERROR_ACCESS_DENIED, which occurs between postmasters exexuted as
service, it can reasonablly be assumed that the segment is
already created by someone else. I think this is no problem
because postgres processes don't need to access someone else's
segments.

Finally, the valid fix would be that make it return false if
GetLastError() == ERROR_ALREADY_EXISTS or ERROR_ACCESS_DENIED.

The patch attached will fix *both of* the problems.

regards,

At Fri, 16 Oct 2015 09:02:41 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in <CAA4eK1+pjtDouF-Lc9y0UgFDmWHnaf4KwiM1Y3Anq0wZ1gwsAA@mail.gmail.com>

I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error. Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c. I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).

--
Kyotaro Horiguchi
NTT Open Source Software Center

Sorry, forgot to close the valid handle on return.

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

It seems somewhat strange. Looking into the create operation in
dms_impl_posix(), it should return false but not emit error when
the shared memory object already exists.

So, to make the windows version behave as the same,
dsm_impl_windows should return false if GetLastError() ==
ERROR_ALREADY_EXISTS regardless of hmap is valid. The current
behavior is wrong because two or more postmaster *share* the same
DSM segment instead of having their own segments.

On the other hand, in the case of GetLastError() ==
ERROR_ACCESS_DENIED, which occurs between postmasters exexuted as
service, it can reasonablly be assumed that the segment is
already created by someone else. I think this is no problem
because postgres processes don't need to access someone else's
segments.

Finally, the valid fix would be that make it return false if
GetLastError() == ERROR_ALREADY_EXISTS or ERROR_ACCESS_DENIED.

The patch attached will fix *both of* the problems.

regards,

At Fri, 16 Oct 2015 09:02:41 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in <CAA4eK1+pjtDouF-Lc9y0UgFDmWHnaf4KwiM1Y3Anq0wZ1gwsAA@mail.gmail.com>

I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error. Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c. I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).

--
Kyotaro Horiguchi
NTT Open Source Software Center

This is wrong, current code does well for this case. I should
broke the code during investigating the problem.

So, to make the windows version behave as the same,
dsm_impl_windows should return false if GetLastError() ==
ERROR_ALREADY_EXISTS regardless of hmap is valid. The current
behavior is wrong because two or more postmaster *share* the same
DSM segment instead of having their own segments.

The patch attached will fix *both of* the problems.

So, the patch fixes only the "Permission denied" case.

regards,

At Fri, 16 Oct 2015 14:37:47 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20151016.143747.121283630.horiguchi.kyotaro@lab.ntt.co.jp>

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

It seems somewhat strange. Looking into the create operation in
dms_impl_posix(), it should return false but not emit error when
the shared memory object already exists.

So, to make the windows version behave as the same,
dsm_impl_windows should return false if GetLastError() ==
ERROR_ALREADY_EXISTS regardless of hmap is valid. The current
behavior is wrong because two or more postmaster *share* the same
DSM segment instead of having their own segments.

On the other hand, in the case of GetLastError() ==
ERROR_ACCESS_DENIED, which occurs between postmasters exexuted as
service, it can reasonablly be assumed that the segment is
already created by someone else. I think this is no problem
because postgres processes don't need to access someone else's
segments.

Finally, the valid fix would be that make it return false if
GetLastError() == ERROR_ALREADY_EXISTS or ERROR_ACCESS_DENIED.

The patch attached will fix *both of* the problems.

regards,

At Fri, 16 Oct 2015 09:02:41 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in <CAA4eK1+pjtDouF-Lc9y0UgFDmWHnaf4KwiM1Y3Anq0wZ1gwsAA@mail.gmail.com>

I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG. Can you please try with the attached patch and see
if the issue is fixed for you.

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error. Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c. I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).

--
Kyotaro Horiguchi
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Oct 16, 2015 at 12:16 PM, Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp> wrote:

This is wrong, current code does well for this case. I should
broke the code during investigating the problem.

So, to make the windows version behave as the same,
dsm_impl_windows should return false if GetLastError() ==
ERROR_ALREADY_EXISTS regardless of hmap is valid. The current
behavior is wrong because two or more postmaster *share* the same
DSM segment instead of having their own segments.

The patch attached will fix *both of* the problems.

So, the patch fixes only the "Permission denied" case.

Why do you think it is bad to display even log for "Permission denied"
case?
It seems all other implementations does the same and I think it is
useful information and we should log it. Don't you think the patch
sent by me is good enough to fix the reported issue?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Пт, 2015-10-16 at 09:02 +0530, Amit Kapila wrote:

On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev <d.vasilyev@postgres
pro.ru> wrote:

I think that function dsm_impl_windows() with EACCES error should
not
do ereport() with FATAL level. It works, but it is likely to make
an
infinite loop if the user will receive EACCES error.

Currently we are using error level as ERROR for creating dsm during
postmaster startup which is not right and rather we should use error
level as LOG.  Can you please try with the attached patch and see
if the issue is fixed for you.

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at
least
thats what happening on windows) due to which you are seeing the
error.  Another options could be to append current pid or data
directory
path as we are doing in win32_shmem.c.  I think this could be an
optimization which can be done in addition to the fix attached (we
can
do this as a separate patch as well, if we agreed to do anything).

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In that case your patch is working. There was LOG level message with Permission denied (from the operation point it’s not clear how to respond to message like this).
But as I understand if operating system can’t create shared memory we will try to distinguish that chunk up to infinity.
As I see it’s better to stop instance in this case.
So I guess it’s a good idea to remain all as it is now (FATAL level) but add PostmasterPid to name (as you suggest). There’s patch in attachments.

----
Dmitry Vasilyev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error. Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c. I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).

Maybe we need to be using PostmasterRandom() rather than random() for
the control segment name.

But regardless, this patch isn't the right fix.
dsm_impl_op(DSM_OP_CREATE, ...) is supposed to return false in the
event of a segment-already-exists condition, without ereporting. If
it hits any OTHER error, then it should ereport(). In the Windows
implementation, the code that caters to this is here:

if (errno == EEXIST)
{
/*
* On Windows, when the segment already exists, a handle for the
* existing segment is returned. We must close it before
* returning. We don't do _dosmaperr here, so errno won't be
* modified.
*/
CloseHandle(hmap);
return false;
}

Kyotaro Horiguchi's analysis seems to me to be going in about the
right direction.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

Another some what related point is currently we are using random()
function to ensure a unique name for dsm and it seems to me that
it is always going to generate same number on first invocation (at least
thats what happening on windows) due to which you are seeing the
error. Another options could be to append current pid or data directory
path as we are doing in win32_shmem.c. I think this could be an
optimization which can be done in addition to the fix attached (we can
do this as a separate patch as well, if we agreed to do anything).

Maybe we need to be using PostmasterRandom() rather than random() for
the control segment name.

+1. Though I think it is better to investigate the actual cause before
doing
this.

But regardless, this patch isn't the right fix.
dsm_impl_op(DSM_OP_CREATE, ...) is supposed to return false in the
event of a segment-already-exists condition, without ereporting.

Thats right, but in this case, it seems from what is reported, that we are
hitting Access Denied error which on retry seems to disappear (which
ideally shouldn't happen). It's not clear to me why that is happening.

By reading code, it appears that previously when we get such errors
for main shared memory, we replaced the usage of 'Global\PostreSQL:..'
to 'Global/PostgreSQL:.. (refer GetSharedMemName()), but in case of
dsm we have already taken care of same, so not sure what else could
be reason for Access Denied error.

Dmitry, can we try to see what is the exact value of GetLastError()
when it fails (one way is to check the logs at DEBUG5 level,
_dosmaperr() will print that value or you can modify the code to see it.)

Which Windows version you are using?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Amit Kapila <amit.kapila16@gmail.com> writes:

On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Maybe we need to be using PostmasterRandom() rather than random() for
the control segment name.

+1. Though I think it is better to investigate the actual cause before
doing this.

BackendRun() deliberately prevents that from working. And it also sets
srandom() to a new value for each subprocess, so that AFAICS this idea
would be a net negative. If you are seeing duplicate key values getting
selected, the problem is elsewhere.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Oct 18, 2015 at 1:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Amit Kapila <amit.kapila16@gmail.com> writes:

On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Maybe we need to be using PostmasterRandom() rather than random() for
the control segment name.

+1. Though I think it is better to investigate the actual cause before
doing this.

BackendRun() deliberately prevents that from working. And it also sets
srandom() to a new value for each subprocess, so that AFAICS this idea
would be a net negative. If you are seeing duplicate key values getting
selected, the problem is elsewhere.

Coming back to an old thread, recently I got a problem in starting two
PostgreSQL services with a user that is not an administrator. The error
message is as follows.

FATAL: could not create shared memory segment
"Global/PostgreSQL.851401618": Permission denied

The issue is happening only with the processes that are running as service.
I observed that the handle received in creating the dynamic shared memory
is same for two services, because of which the Access denied error is thrown
by the operating system and thus it leads to failure.

The PG shared memory name is always includes the data directory path as
below, because of which it doesn't match with two services.

"Global/PostgreSQL:C:/work/FEP/installation/bin/data"

But whereas the dynamic shared memory is formed with a random number
and this number getting generated same for two service thus it leads to
failure.

"Global/PostgreSQL.85140161"

I tried replacing the random() with PostmaterRandom() for a test and it worked.
This is generating different random values, so the issue is not occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number to
generate the name for dynamic shared memory, this can fix problem.

comments?

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

I tried replacing the random() with PostmaterRandom() for a test and it

worked.

This is generating different random values, so the issue is not occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number to
generate the name for dynamic shared memory, this can fix problem.

As mentioned above, I think if we can investigate why this error is
generated, that will be helpful. Currently the code ensures that if the
segment already exists, it should retry to create a segment with other name
(refer dsm_impl_windows()), so the point of investigation is, why it is not
going via that path? I am guessing due to some reason CreateFileMapping()
is returning NULL in this case whereas ideally it should return the
existing handle with an error ERROR_ALREADY_EXISTS.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

I tried replacing the random() with PostmaterRandom() for a test and it
worked.
This is generating different random values, so the issue is not occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number to
generate the name for dynamic shared memory, this can fix problem.

As mentioned above, I think if we can investigate why this error is
generated, that will be helpful. Currently the code ensures that if the
segment already exists, it should retry to create a segment with other name
(refer dsm_impl_windows()), so the point of investigation is, why it is not
going via that path? I am guessing due to some reason CreateFileMapping()
is returning NULL in this case whereas ideally it should return the existing
handle with an error ERROR_ALREADY_EXISTS.

DEBUG: mapped win32 error code 5 to 13

Yes, the CreateFileMapping() is returning NULL with an error of
ERROR_ACCESS_DENIED.
I am not able to find the reason for this error. This error is occurring only
when the PostgreSQL is started as a service only.

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Mar 9, 2016 at 7:16 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:

On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

I tried replacing the random() with PostmaterRandom() for a test and it
worked.
This is generating different random values, so the issue is not occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number to
generate the name for dynamic shared memory, this can fix problem.

As mentioned above, I think if we can investigate why this error is
generated, that will be helpful. Currently the code ensures that if the
segment already exists, it should retry to create a segment with other name
(refer dsm_impl_windows()), so the point of investigation is, why it is not
going via that path? I am guessing due to some reason CreateFileMapping()
is returning NULL in this case whereas ideally it should return the existing
handle with an error ERROR_ALREADY_EXISTS.

DEBUG: mapped win32 error code 5 to 13

Yes, the CreateFileMapping() is returning NULL with an error of
ERROR_ACCESS_DENIED.
I am not able to find the reason for this error. This error is occurring only
when the PostgreSQL is started as a service only.

Another question is: why are both postmasters returning the same
random number? That's not very, uh, random.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Mar 10, 2016 at 5:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Wed, Mar 9, 2016 at 7:16 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:

On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

I tried replacing the random() with PostmaterRandom() for a test and it
worked.
This is generating different random values, so the issue is not occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number to
generate the name for dynamic shared memory, this can fix problem.

As mentioned above, I think if we can investigate why this error is
generated, that will be helpful. Currently the code ensures that if the
segment already exists, it should retry to create a segment with other name
(refer dsm_impl_windows()), so the point of investigation is, why it is not
going via that path? I am guessing due to some reason CreateFileMapping()
is returning NULL in this case whereas ideally it should return the existing
handle with an error ERROR_ALREADY_EXISTS.

DEBUG: mapped win32 error code 5 to 13

Yes, the CreateFileMapping() is returning NULL with an error of
ERROR_ACCESS_DENIED.
I am not able to find the reason for this error. This error is occurring only
when the PostgreSQL is started as a service only.

Another question is: why are both postmasters returning the same
random number? That's not very, uh, random.

The random number is generated from our own implementation of
random function. The random function internally calls the pg_lrand48
function to get the random value. This function generates the random
number based on specified random seed and pre-defined calculations.
Because of this reason, the same random number is getting generated
every time.

In LInux, the random function is used from the glibc, there also it is
generating the same random number as the first number, but if the
number is used by some process then it is generating a different random
number for the next PostgreSQL process.

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Mar 9, 2016 at 5:46 PM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi <

kommi.haribabu@gmail.com>

wrote:

I tried replacing the random() with PostmaterRandom() for a test and it
worked.
This is generating different random values, so the issue is not

occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number

to

generate the name for dynamic shared memory, this can fix problem.

As mentioned above, I think if we can investigate why this error is
generated, that will be helpful. Currently the code ensures that if the
segment already exists, it should retry to create a segment with other

name

(refer dsm_impl_windows()), so the point of investigation is, why it is

not

going via that path? I am guessing due to some reason

CreateFileMapping()

is returning NULL in this case whereas ideally it should return the

existing

handle with an error ERROR_ALREADY_EXISTS.

DEBUG: mapped win32 error code 5 to 13

Yes, the CreateFileMapping() is returning NULL with an error of
ERROR_ACCESS_DENIED.

Okay, so one probable theory for such an error could be that when there is
already an object with same name exists, this API requests access to the
that existing object and found that it can't access it due to some reason.
On googling, I found some people suggesting to try by disabling UAC [1]http://windows.microsoft.com/en-in/windows/turn-user-account-control-on-off#1TC=windows-7 on
your m/c, can you once try that to see what is the result (this experiment
is just to find out the actual reason of failure, rather than a permanent
change suggestion).

I am not able to find the reason for this error. This error is occurring

only

when the PostgreSQL is started as a service only.

Did you use pg_ctl register/unregister to register different services. Can
you share the detail steps and OS version on which you saw this behaviour?

[1]: http://windows.microsoft.com/en-in/windows/turn-user-account-control-on-off#1TC=windows-7
http://windows.microsoft.com/en-in/windows/turn-user-account-control-on-off#1TC=windows-7

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Fri, Mar 11, 2016 at 12:00 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Wed, Mar 9, 2016 at 5:46 PM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi
<kommi.haribabu@gmail.com>
wrote:

I tried replacing the random() with PostmaterRandom() for a test and it
worked.
This is generating different random values, so the issue is not
occurring.

"Global/PostgreSQL.2115609797"

I feel, we should add the the data directory path + the random number
to
generate the name for dynamic shared memory, this can fix problem.

As mentioned above, I think if we can investigate why this error is
generated, that will be helpful. Currently the code ensures that if the
segment already exists, it should retry to create a segment with other
name
(refer dsm_impl_windows()), so the point of investigation is, why it is
not
going via that path? I am guessing due to some reason
CreateFileMapping()
is returning NULL in this case whereas ideally it should return the
existing
handle with an error ERROR_ALREADY_EXISTS.

DEBUG: mapped win32 error code 5 to 13

Yes, the CreateFileMapping() is returning NULL with an error of
ERROR_ACCESS_DENIED.

Okay, so one probable theory for such an error could be that when there is
already an object with same name exists, this API requests access to the
that existing object and found that it can't access it due to some reason.
On googling, I found some people suggesting to try by disabling UAC [1] on
your m/c, can you once try that to see what is the result (this experiment
is just to find out the actual reason of failure, rather than a permanent
change suggestion).

Thanks for the details. Currently I am unable to change the UAC settings in my
laptop. I will try to do it in a different system and let you know the
result later.

I am not able to find the reason for this error. This error is occurring
only
when the PostgreSQL is started as a service only.

Did you use pg_ctl register/unregister to register different services. Can
you share the detail steps and OS version on which you saw this behaviour?

Operating system - windows 7
Binary - PostgreSQL 9.5 (This doesn't matter, 9.4+ can produce the problem)

1. Create two standard users in the system (test_user1 and test_user2)
2. Create two databases belongs each user listed above.
3. Now using pg_ctl register the services for the two users.
4. Provide logon permissions to these users to run the services by changing
service properties.
5. Now try to start the services, the second service fails with the
error message.
6. Error details can be found out in Event log viewer.

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Mar 11, 2016 at 5:21 PM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

On Fri, Mar 11, 2016 at 12:00 AM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

Okay, so one probable theory for such an error could be that when there

is

already an object with same name exists, this API requests access to the
that existing object and found that it can't access it due to some

reason.

On googling, I found some people suggesting to try by disabling UAC [1]

on

your m/c, can you once try that to see what is the result (this

experiment

is just to find out the actual reason of failure, rather than a

permanent

change suggestion).

Thanks for the details. Currently I am unable to change the UAC settings

in my

laptop. I will try to do it in a different system and let you know the
result later.

I am not able to find the reason for this error. This error is

occurring

only
when the PostgreSQL is started as a service only.

Did you use pg_ctl register/unregister to register different services.

Can

you share the detail steps and OS version on which you saw this

behaviour?

Operating system - windows 7
Binary - PostgreSQL 9.5 (This doesn't matter, 9.4+ can produce the

problem)

1. Create two standard users in the system (test_user1 and test_user2)

I think one possibility is that one user is not able to access the object
created by another user, if possible can you as well try with just one user
(Have same user for both the services).

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Fri, Mar 11, 2016 at 11:15 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Fri, Mar 11, 2016 at 5:21 PM, Haribabu Kommi <kommi.haribabu@gmail.com>
wrote:

On Fri, Mar 11, 2016 at 12:00 AM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

Okay, so one probable theory for such an error could be that when there
is
already an object with same name exists, this API requests access to the
that existing object and found that it can't access it due to some
reason.
On googling, I found some people suggesting to try by disabling UAC [1]
on
your m/c, can you once try that to see what is the result (this
experiment
is just to find out the actual reason of failure, rather than a
permanent
change suggestion).

Thanks for the details. Currently I am unable to change the UAC settings
in my
laptop. I will try to do it in a different system and let you know the
result later.

I am not able to find the reason for this error. This error is
occurring
only
when the PostgreSQL is started as a service only.

Did you use pg_ctl register/unregister to register different services.
Can
you share the detail steps and OS version on which you saw this
behaviour?

Operating system - windows 7
Binary - PostgreSQL 9.5 (This doesn't matter, 9.4+ can produce the
problem)

1. Create two standard users in the system (test_user1 and test_user2)

I think one possibility is that one user is not able to access the object
created by another user, if possible can you as well try with just one user
(Have same user for both the services).

Yes, it is working as same user services. The main problem is, PostgreSQL
as a service for two different users in the same system is not working because
of same random getting generated for two services.

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers