Обсуждение: [BUGS] Re: [PATCH] BUG #13416: Postgres >= 9.3 doesn'tuse optimized shared memory on Solaris anymore
[BUGS] Re: [PATCH] BUG #13416: Postgres >= 9.3 doesn'tuse optimized shared memory on Solaris anymore
От
Sean Chittenden
Дата:
Hello. We identified the same problem. Sam Gwydir and Josh Clulow were able to put together the appropriate fix after.
The breakage in src/backend/port/sysv_shmem.c and src/include/storage/dsm_impl.h should be back ported to all supported versions (the regression was introduced between the 9.2 and 9.3 branches).
The only real question remaining is: do we want to change the default behavior, as detected by initdb(1), to use ISM on Illumos/Solaris derived systems? Given the memory bloat experienced when using POSIX shared memory (potentially very significant for systems with larger shared_buffers), we think it's probably prudent to change the default from
dynamic_shared_memory_type=posix to sysv. Unfortunately I think it's not worth changing the default behavior of initdb(1) in the current supported branches, but it should be changed for 10.Please let us know if there are any questions. -sc
--
Sean Chittenden
seanc@joyent.com
Sean Chittenden
seanc@joyent.com
Вложения
[BUGS] Re: [PATCH] BUG #13416: Postgres >= 9.3 doesn'tuse optimized shared memory on Solaris anymore
От
Sean Chittenden
Дата:
Hello. We identified the same problem. Sam Gwydir and Josh Clulow were able to put together the appropriate fix after.
The breakage in src/backend/port/sysv_shmem.c and src/include/storage/dsm_impl.h should be back ported to all supported versions (the regression was introduced between the 9.2 and 9.3 branches).
The only real question remaining is: do we want to change the default behavior, as detected by initdb(1), to use ISM on Illumos/Solaris derived systems? Given the memory bloat experienced when using POSIX shared memory (potentially very significant for systems with larger shared_buffers), we think it's probably prudent to change the default from dynamic_shared_memory_type=posix to sysv. Unfortunately I think it's not worth changing the default behavior of initdb(1) in the current supported branches, but it should be changed for 10.
Please let us know if there are any questions. -sc
--
Sean Chittenden
seanc@joyent.com
The breakage in src/backend/port/sysv_shmem.c and src/include/storage/dsm_impl.h should be back ported to all supported versions (the regression was introduced between the 9.2 and 9.3 branches).
The only real question remaining is: do we want to change the default behavior, as detected by initdb(1), to use ISM on Illumos/Solaris derived systems? Given the memory bloat experienced when using POSIX shared memory (potentially very significant for systems with larger shared_buffers), we think it's probably prudent to change the default from dynamic_shared_memory_type=posix to sysv. Unfortunately I think it's not worth changing the default behavior of initdb(1) in the current supported branches, but it should be changed for 10.
Please let us know if there are any questions. -sc
--
Sean Chittenden
seanc@joyent.com
Hi, On 2017-10-04 10:47:06 -0700, Sean Chittenden wrote: > Hello. We identified the same problem. Sam Gwydir and Josh Clulow were able to put together the appropriate fix after. > > The breakage in src/backend/port/sysv_shmem.c and src/include/storage/dsm_impl.h should be back ported to all supportedversions (the regression was introduced between the 9.2 and 9.3 branches). Personally I don't think "breakage" is quite the right work. I also don't like that we're unconditionally not using USE_ANONYMOUS_SHMEM - doesn't that run into similar config limits on solaris based stuff as it does on linux etc? I think if we want to do this, we should rather go with a patch like https://www.postgresql.org/message-id/20140422121921.GD4449@awork2.anarazel.de Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Fair enough. We observed a ~4x amplification in memory usage so it was rather severe in our case.
The patch you referenced was a much nicer approach and Sam updated it to match that style (thank you Sam!). We debated this internally and feel strongly that this should be exposed as a runtime GUC as suggested. What's your take on the attached patch?
-sc
--
Sean Chittenden
seanc@joyent.com
On Oct 4, 2017, 10:56 AM -0700, Andres Freund <andres@anarazel.de>, wrote:
Hi,
On 2017-10-04 10:47:06 -0700, Sean Chittenden wrote:Hello. We identified the same problem. Sam Gwydir and Josh Clulow were able to put together the appropriate fix after.
The breakage in src/backend/port/sysv_shmem.c and src/include/storage/dsm_impl.h should be back ported to all supported versions (the regression was introduced between the 9.2 and 9.3 branches).
Personally I don't think "breakage" is quite the right work.
I also don't like that we're unconditionally not using
USE_ANONYMOUS_SHMEM - doesn't that run into similar config limits on
solaris based stuff as it does on linux etc?
I think if we want to do this, we should rather go with a patch like
https://www.postgresql.org/message-id/20140422121921.GD4449@awork2.anarazel.de
Greetings,
Andres Freund