Shared memory changes in 9.4?

Maciek Sakrejda <m.sakrejda@gmail.com> writes:

I've been trying to take the 9.4 beta for a spin, but seem to have run into
a shared memory issue on startup:

FATAL: could not open shared memory segment "/PostgreSQL.1804289383":
Permission denied

We're running Postgres inside LXC, which I suspect is causing problems
here, but 9.0 through 9.3 run just fine in the same configuration. Any idea
what may have changed? I suspect the solution here is tweaking some LXC
setting, but I was hoping someone can point me in the right direction.

This message is coming out of the new "dynamic shared memory" code.
I'm not real sure why that's being invoked at startup; perhaps Robert Haas
can elucidate. Anyway the short answer is that this sounds like a
portability hazard in the new code in src/backend/storage/ipc/dsm_impl.c.
Perhaps you can look into that and identify what's up.

regards, tom lane

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

Hi,

On 2014-05-25 12:26:20 -0700, Maciek Sakrejda wrote:

I've been trying to take the 9.4 beta for a spin, but seem to have run into
a shared memory issue on startup:

FATAL: could not open shared memory segment "/PostgreSQL.1804289383":
Permission denied

We're running Postgres inside LXC, which I suspect is causing problems
here, but 9.0 through 9.3 run just fine in the same configuration.

Any chance you're using a 9.3 configuration file instead of the one
generated by initdb?
dynamic_shared_memory_type defaults to 'posix' if not specified in the
config file (on platforms supporting it). If initdb detects that 'posix'
can't be used it'll emit a different value. If you're copying the config
from 9.3 and your environment doesn't support posix shm that'll cause
the above error.
I still think dynamic_shared_memory_type should default to 'none'
because of such problems.

Any idea
what may have changed? I suspect the solution here is tweaking some LXC
setting, but I was hoping someone can point me in the right direction.

It sounds like you're not allowing posix shared memory. Possibly just by
not mounting /dev/shm.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On Mon, May 26, 2014 at 12:24 AM, Andres Freund <andres@2ndquadrant.com>wrote:

Any chance you're using a 9.3 configuration file instead of the one
generated by initdb?
dynamic_shared_memory_type defaults to 'posix' if not specified in the
config file (on platforms supporting it). If initdb detects that 'posix'
can't be used it'll emit a different value. If you're copying the config
from 9.3 and your environment doesn't support posix shm that'll cause
the above error.
I still think dynamic_shared_memory_type should default to 'none'
because of such problems.

It works with 'none' and 'sysv'--I think the issue is that technically our
environment does support 'posix', but '/dev/shm' is indeed not mounted in
the LXC container, leading to a discrepancy between what initdb decides and
what's actually possible. Thanks for your help.

Thanks,
Maciek

On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda <m.sakrejda@gmail.com> wrote:

On Mon, May 26, 2014 at 12:24 AM, Andres Freund <andres@2ndquadrant.com>
wrote:

Any chance you're using a 9.3 configuration file instead of the one
generated by initdb?
dynamic_shared_memory_type defaults to 'posix' if not specified in the
config file (on platforms supporting it). If initdb detects that 'posix'
can't be used it'll emit a different value. If you're copying the config
from 9.3 and your environment doesn't support posix shm that'll cause
the above error.
I still think dynamic_shared_memory_type should default to 'none'
because of such problems

It works with 'none' and 'sysv'--I think the issue is that technically our
environment does support 'posix', but '/dev/shm' is indeed not mounted in
the LXC container, leading to a discrepancy between what initdb decides and
what's actually possible. Thanks for your help.

I think it would be good to understand why initdb isn't getting this
right. Did you run initdb outside the LXC container, where /dev/shm
would have worked, but then run postgres inside the LXC container,
where /dev/shm does not work? I ask because initdb is supposed to be
doing the same thing that postgres does, so it really ought to come to
the same conclusion about what will and won't work.

With regard to Andres' proposal, I'm not that keen on setting
dynamic_shared_memory_type='none' by default. Would we leave it that
way until we get in-core users of the facility, and then change it? I
guess that'd be OK, but frankly if enabling dynamic_shared_memory_type
by default is causing us many problems, then we'd better reconsider
the design of the facility now, before we start adding more
dependencies on it. We've already fixed a bunch of DSM-related issues
as a result of the fact that the default *isn't* none, and I dunno how
many of those we would have found if the default had been none. I
tend to think DSM is an important facility that we're going to be
wanting to build on in future releases, so I'm keen to have it
available by default so that we can iron out any kinks before we get
too far down that path.

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

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

On Tue, May 27, 2014 at 8:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:

I think it would be good to understand why initdb isn't getting this
right. Did you run initdb outside the LXC container, where /dev/shm
would have worked, but then run postgres inside the LXC container,
where /dev/shm does not work? I ask because initdb is supposed to be
doing the same thing that postgres does, so it really ought to come to
the same conclusion about what will and won't work.

You're absolutely right--I thought initdb was containerized as well, but
I looked at our code and this is exactly what's happening.

....We've already fixed a bunch of DSM-related issues
as a result of the fact that the default *isn't* none, and I dunno how
many of those we would have found if the default had been none.

For what it's worth, +1. I'm not sure whether or not we had a good reason
for
doing initdb outside the container, but it's definitely an aberrant
configuration,
and should not be taken as evidence that the current default is a problem.

[redirecting to -hackers]

Re: Robert Haas 2014-05-28 <CA+TgmoaTcAd48zW3auWzGdHi_V+QwA5HVCTabqgTq=ZLWpysEQ@mail.gmail.com>

On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda <m.sakrejda@gmail.com> wrote:

On Mon, May 26, 2014 at 12:24 AM, Andres Freund <andres@2ndquadrant.com>
wrote:

Any chance you're using a 9.3 configuration file instead of the one
generated by initdb?
dynamic_shared_memory_type defaults to 'posix' if not specified in the
config file (on platforms supporting it). If initdb detects that 'posix'
can't be used it'll emit a different value. If you're copying the config
from 9.3 and your environment doesn't support posix shm that'll cause
the above error.
I still think dynamic_shared_memory_type should default to 'none'
because of such problems

It works with 'none' and 'sysv'--I think the issue is that technically our
environment does support 'posix', but '/dev/shm' is indeed not mounted in
the LXC container, leading to a discrepancy between what initdb decides and
what's actually possible. Thanks for your help.

I think it would be good to understand why initdb isn't getting this
right. Did you run initdb outside the LXC container, where /dev/shm
would have worked, but then run postgres inside the LXC container,
where /dev/shm does not work? I ask because initdb is supposed to be
doing the same thing that postgres does, so it really ought to come to
the same conclusion about what will and won't work.

With regard to Andres' proposal, I'm not that keen on setting
dynamic_shared_memory_type='none' by default. Would we leave it that
way until we get in-core users of the facility, and then change it? I
guess that'd be OK, but frankly if enabling dynamic_shared_memory_type
by default is causing us many problems, then we'd better reconsider
the design of the facility now, before we start adding more
dependencies on it. We've already fixed a bunch of DSM-related issues
as a result of the fact that the default *isn't* none, and I dunno how
many of those we would have found if the default had been none. I
tend to think DSM is an important facility that we're going to be
wanting to build on in future releases, so I'm keen to have it
available by default so that we can iron out any kinks before we get
too far down that path.

Hi,

I've just run into the same problem. I am running the Debian
postgresql-common testsuite, which includes upgrade tests. On
upgrades, the old postgresql.conf is copied to the new server (after
initdb and/or pg_upgrade), and deprecated options are removed/renamed. [*]

In that chroot environment, 9.4 is running fine, except that upgrades
failed because /dev/shm wasn't mounted, and the old 9.3
postgresql.conf doesn't contain dynamic_shared_memory_type = 'sysv'.

To me, the following should be done:
* Make initdb determine the best shm type for this platform and write
it into postgresql.conf as it does now.
* If no dynamic_shared_memory_type is found in the config, default to
"none".
* Modify the three identical error messages concerned about shm
segments to include the shm type instead of always just saying
"FATAL: could not open shared memory segment"
* Add a HINT to the POSIX error message:
"HINT: This might indicate that /dev/shm is not mounted, or its
permissions do not allow the database user to create files there"

Despite /dev/shm having been around for quite some time, many people
seem to be unaware what POSIX shared memory is, so the HINT is really
needed there. It certainly took me weeks after seeing the error
message the first time till I found the time to dig deeper to the
issure - it should just have been "oh yes, /dev/shm isn't mounted
there, that's why".

Christoph

[*] This might not be the smartest thing to do, but it's a simple
default approach to get the new cluster running with as much user
config from the old config as possible.
--
cb@df7cb.de | http://www.df7cb.de/

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

Hi,

On 2014-06-12 11:07:31 +0200, Christoph Berg wrote:

Re: Robert Haas 2014-05-28 <CA+TgmoaTcAd48zW3auWzGdHi_V+QwA5HVCTabqgTq=ZLWpysEQ@mail.gmail.com>

On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda <m.sakrejda@gmail.com> wrote:

On Mon, May 26, 2014 at 12:24 AM, Andres Freund <andres@2ndquadrant.com>
wrote:

Any chance you're using a 9.3 configuration file instead of the one
generated by initdb?
dynamic_shared_memory_type defaults to 'posix' if not specified in the
config file (on platforms supporting it). If initdb detects that 'posix'
can't be used it'll emit a different value. If you're copying the config
from 9.3 and your environment doesn't support posix shm that'll cause
the above error.
I still think dynamic_shared_memory_type should default to 'none'
because of such problems

With regard to Andres' proposal, I'm not that keen on setting
dynamic_shared_memory_type='none' by default.

Note that I'm not proposing to disable the whole thing. Just that a
unset dynamic_shared_memory_type doesn't configure dsm. Initdb would
still configure it after probing.

To me, the following should be done:
* Make initdb determine the best shm type for this platform and write
it into postgresql.conf as it does now.
* If no dynamic_shared_memory_type is found in the config, default to
"none".
* Modify the three identical error messages concerned about shm
segments to include the shm type instead of always just saying
"FATAL: could not open shared memory segment"
* Add a HINT to the POSIX error message:
"HINT: This might indicate that /dev/shm is not mounted, or its
permissions do not allow the database user to create files there"

Sounds like a sane plan to me.

Greetings,

Andres Freund

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

Re: Andres Freund 2014-06-12 <20140612094112.GZ8406@alap3.anarazel.de>

* Make initdb determine the best shm type for this platform and write
it into postgresql.conf as it does now.
* If no dynamic_shared_memory_type is found in the config, default to
"none".
* Modify the three identical error messages concerned about shm
segments to include the shm type instead of always just saying
"FATAL: could not open shared memory segment"
* Add a HINT to the POSIX error message:
"HINT: This might indicate that /dev/shm is not mounted, or its
permissions do not allow the database user to create files there"

Sounds like a sane plan to me.

Here are two patches, one that implements the annotated error
messages, and one that selects none as default.

It might also make sense to add a Note that POSIX depends on /dev/shm,
and also a Note that dynamic_shared_memory_type is not related to
the shared_buffers shm segments, which I didn't include here.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

On Thu, Jun 12, 2014 at 5:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:

With regard to Andres' proposal, I'm not that keen on setting
dynamic_shared_memory_type='none' by default.

Note that I'm not proposing to disable the whole thing. Just that a
unset dynamic_shared_memory_type doesn't configure dsm. Initdb would
still configure it after probing.

OK, I misunderstood your position; thanks for clarifying. I think
that would be OK with me. To some degree, I think that the test setup
is broken by design: while we try to maintain backward-compatibility
for postgresql.conf files, there's never been any guarantee that an
old postgresql.conf file will work on a newer server. For example, a
whole lot of pre-8.4 users probably had max_fsm_pages and
max_fsm_relations configured, and with 8.4, those settings went away.
Fixing that kind of thing is an essential part of the upgrade process.

That having been said, in this particular case, we can probably ease
the pain without much downside by doing as you suggest. The only
thing I'm worried about is that people will discover much later that
they don't have working dynamic shared memory, and be unhappy about
that. Sometimes it's better to complain loudly at the beginning than
to leave buried problems for later. But I'll defer to the majority on
what to do in his instance.

To me, the following should be done:
* Make initdb determine the best shm type for this platform and write
it into postgresql.conf as it does now.
* If no dynamic_shared_memory_type is found in the config, default to
"none".
* Modify the three identical error messages concerned about shm
segments to include the shm type instead of always just saying
"FATAL: could not open shared memory segment"
* Add a HINT to the POSIX error message:
"HINT: This might indicate that /dev/shm is not mounted, or its
permissions do not allow the database user to create files there"

Sounds like a sane plan to me.

+1 to the rest of this.

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

Hi,

On 2014-06-12 11:08:35 -0400, Robert Haas wrote:

On Thu, Jun 12, 2014 at 5:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:

With regard to Andres' proposal, I'm not that keen on setting
dynamic_shared_memory_type='none' by default.

Note that I'm not proposing to disable the whole thing. Just that a
unset dynamic_shared_memory_type doesn't configure dsm. Initdb would
still configure it after probing.

OK, I misunderstood your position; thanks for clarifying. I think
that would be OK with me. To some degree, I think that the test setup
is broken by design: while we try to maintain backward-compatibility
for postgresql.conf files, there's never been any guarantee that an
old postgresql.conf file will work on a newer server. For example, a
whole lot of pre-8.4 users probably had max_fsm_pages and
max_fsm_relations configured, and with 8.4, those settings went away.
Fixing that kind of thing is an essential part of the upgrade process.

While I think I see where you're coming from I don't think these cases
are comparable. In this case commenting out the GUC can prevent the
server from starting. That's pretty odd imo.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

Uh, this patch was never applied. Do we want it?

---------------------------------------------------------------------------

On Thu, Jun 12, 2014 at 03:39:14PM +0200, Christoph Berg wrote:

Re: Andres Freund 2014-06-12 <20140612094112.GZ8406@alap3.anarazel.de>

* Make initdb determine the best shm type for this platform and write
it into postgresql.conf as it does now.
* If no dynamic_shared_memory_type is found in the config, default to
"none".
* Modify the three identical error messages concerned about shm
segments to include the shm type instead of always just saying
"FATAL: could not open shared memory segment"
* Add a HINT to the POSIX error message:
"HINT: This might indicate that /dev/shm is not mounted, or its
permissions do not allow the database user to create files there"

Sounds like a sane plan to me.

Here are two patches, one that implements the annotated error
messages, and one that selects none as default.

It might also make sense to add a Note that POSIX depends on /dev/shm,
and also a Note that dynamic_shared_memory_type is not related to
the shared_buffers shm segments, which I didn't include here.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

diff --git a/src/backend/storage/ipc/dsm_impl.c b/src/backend/storage/ipc/dsm_impl.c
new file mode 100644
index 0819641..780e3a5
*** a/src/backend/storage/ipc/dsm_impl.c
--- b/src/backend/storage/ipc/dsm_impl.c
*************** dsm_impl_posix(dsm_op op, dsm_handle han
*** 289,296 ****
if (errno != EEXIST)
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not open shared memory segment \"%s\": %m",
! 							name)));
return false;
}

--- 289,299 ----
if (errno != EEXIST)
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not open POSIX shared memory segment \"%s\": %m",
! 							name),
! 					 errhint("This error usually means that /dev/shm is not mounted, or its "
! 							 "permissions do not allow the database user to create files "
! 							 "there.")));
return false;
}

*************** dsm_impl_posix(dsm_op op, dsm_handle han
*** 313,319 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not stat shared memory segment \"%s\": %m",
name)));
return false;
}
--- 316,322 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not stat POSIX shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_posix(dsm_op op, dsm_handle han
*** 332,338 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 		 errmsg("could not resize shared memory segment %s to %zu bytes: %m",
name, request_size)));
return false;
}
--- 335,341 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not resize POSIX shared memory segment %s to %zu bytes: %m",
name, request_size)));
return false;
}
*************** dsm_impl_posix(dsm_op op, dsm_handle han
*** 358,364 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap shared memory segment \"%s\": %m",
name)));
return false;
}
--- 361,367 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not unmap POSIX shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_posix(dsm_op op, dsm_handle han
*** 382,388 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not map shared memory segment \"%s\": %m",
name)));
return false;
}
--- 385,391 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not map POSIX shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_sysv(dsm_op op, dsm_handle hand
*** 512,518 ****
errno = save_errno;
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 						 errmsg("could not get shared memory segment: %m")));
}
return false;
}
--- 515,521 ----
errno = save_errno;
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 						 errmsg("could not get System V shared memory segment: %m")));
}
return false;
}
*************** dsm_impl_sysv(dsm_op op, dsm_handle hand
*** 530,536 ****
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap shared memory segment \"%s\": %m",
name)));
return false;
}
--- 533,539 ----
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap System V shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_sysv(dsm_op op, dsm_handle hand
*** 540,546 ****
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not remove shared memory segment \"%s\": %m",
name)));
return false;
}
--- 543,549 ----
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not remove System V shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_sysv(dsm_op op, dsm_handle hand
*** 556,562 ****
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not stat shared memory segment \"%s\": %m",
name)));
return false;
}
--- 559,565 ----
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not stat System V shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_sysv(dsm_op op, dsm_handle hand
*** 577,583 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not map shared memory segment \"%s\": %m",
name)));
return false;
}
--- 580,586 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not map System V shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_windows(dsm_op op, dsm_handle h
*** 645,651 ****
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap shared memory segment \"%s\": %m",
name)));
return false;
}
--- 648,654 ----
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap Windows shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_windows(dsm_op op, dsm_handle h
*** 655,661 ****
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not remove shared memory segment \"%s\": %m",
name)));
return false;
}
--- 658,664 ----
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not remove Windows shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_windows(dsm_op op, dsm_handle h
*** 691,697 ****
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not create shared memory segment \"%s\": %m",
name)));
return false;
}
--- 694,700 ----
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not create Windows shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_windows(dsm_op op, dsm_handle h
*** 718,724 ****
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not open shared memory segment \"%s\": %m",
name)));
return false;
}
--- 721,727 ----
_dosmaperr(GetLastError());
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not open Windows shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_windows(dsm_op op, dsm_handle h
*** 739,745 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not map shared memory segment \"%s\": %m",
name)));
return false;
}
--- 742,748 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not map Windows shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_windows(dsm_op op, dsm_handle h
*** 763,769 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not stat shared memory segment \"%s\": %m",
name)));
return false;
}
--- 766,772 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not stat Windows shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 808,814 ****
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap shared memory segment \"%s\": %m",
name)));
return false;
}
--- 811,817 ----
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap mmap shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 818,824 ****
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not remove shared memory segment \"%s\": %m",
name)));
return false;
}
--- 821,827 ----
{
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				  errmsg("could not remove mmap shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 832,838 ****
if (errno != EEXIST)
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not open shared memory segment \"%s\": %m",
name)));
return false;
}
--- 835,841 ----
if (errno != EEXIST)
ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not open mmap shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 856,862 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not stat shared memory segment \"%s\": %m",
name)));
return false;
}
--- 859,865 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not stat mmap shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 875,881 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 		 errmsg("could not resize shared memory segment %s to %zu bytes: %m",
name, request_size)));
return false;
}
--- 878,884 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not resize mmap shared memory segment %s to %zu bytes: %m",
name, request_size)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 923,929 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 					 errmsg("could not resize shared memory segment %s to %zu bytes: %m",
name, request_size)));
return false;
}
--- 926,932 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not resize mmap shared memory segment %s to %zu bytes: %m",
name, request_size)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 950,956 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				   errmsg("could not unmap shared memory segment \"%s\": %m",
name)));
return false;
}
--- 953,959 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not unmap mmap shared memory segment \"%s\": %m",
name)));
return false;
}
*************** dsm_impl_mmap(dsm_op op, dsm_handle hand
*** 974,980 ****

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! 				 errmsg("could not map shared memory segment \"%s\": %m",
name)));
return false;
}
--- 977,983 ----

ereport(elevel,
(errcode_for_dynamic_shared_memory(),
! errmsg("could not map mmap shared memory segment \"%s\": %m",
name)));
return false;
}

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index 697cf99..db52c77
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** include 'filename'
*** 1416,1429 ****
<literal>windows</> (for Windows shared memory), <literal>mmap</>
(to simulate shared memory using memory-mapped files stored in the
data directory), and <literal>none</> (to disable this feature).
!         Not all values are supported on all platforms; the first supported
!         option is the default for that platform.  The use of the
!         <literal>mmap</> option, which is not the default on any platform,
is generally discouraged because the operating system may write
modified pages back to disk repeatedly, increasing system I/O load;
however, it may be useful for debugging, when the
<literal>pg_dynshmem</> directory is stored on a RAM disk, or when
other shared memory facilities are not available.
</para>
</listitem>
</varlistentry>
--- 1416,1432 ----
<literal>windows</> (for Windows shared memory), <literal>mmap</>
(to simulate shared memory using memory-mapped files stored in the
data directory), and <literal>none</> (to disable this feature).
!         Not all values are supported on all platforms.
!         The use of the <literal>mmap</> option
is generally discouraged because the operating system may write
modified pages back to disk repeatedly, increasing system I/O load;
however, it may be useful for debugging, when the
<literal>pg_dynshmem</> directory is stored on a RAM disk, or when
other shared memory facilities are not available.
+         <application>initdb</> will select a suitable setting for the system.
+         The default, when not configured explicitely in
+         <filename>postgresql.conf</>, is to disable the use of dynamic shared
+         memory.
</para>
</listitem>
</varlistentry>
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
new file mode 100644
index 1d094f0..e73f6c1
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*************** static struct config_enum ConfigureNames
*** 3453,3459 ****
NULL
},
&dynamic_shared_memory_type,
! 		DEFAULT_DYNAMIC_SHARED_MEMORY_TYPE, dynamic_shared_memory_options,
NULL, NULL, NULL
},

--- 3453,3459 ----
NULL
},
&dynamic_shared_memory_type,
! 		DSM_IMPL_NONE, dynamic_shared_memory_options,
NULL, NULL, NULL
},

diff --git a/src/include/storage/dsm_impl.h b/src/include/storage/dsm_impl.h
new file mode 100644
index 6e2a013..aa3487a
*** a/src/include/storage/dsm_impl.h
--- b/src/include/storage/dsm_impl.h
***************
*** 26,41 ****
*/
#ifdef WIN32
#define USE_DSM_WINDOWS
- #define DEFAULT_DYNAMIC_SHARED_MEMORY_TYPE		DSM_IMPL_WINDOWS
#else
#ifdef HAVE_SHM_OPEN
#define USE_DSM_POSIX
- #define DEFAULT_DYNAMIC_SHARED_MEMORY_TYPE		DSM_IMPL_POSIX
#endif
#define USE_DSM_SYSV
- #ifndef DEFAULT_DYNAMIC_SHARED_MEMORY_TYPE
- #define DEFAULT_DYNAMIC_SHARED_MEMORY_TYPE		DSM_IMPL_SYSV
- #endif
#define USE_DSM_MMAP
#endif

--- 26,36 ----

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

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

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