On Fri, Aug 12, 2016 at 9:22 PM, Thomas Munro
<thomas.mu...@enterprisedb.com> wrote:
> On Sat, Aug 13, 2016 at 8:26 AM, Thomas Munro
> <thomas.mu...@enterprisedb.com> wrote:
>> On Sat, Aug 13, 2016 at 2:08 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> amul sul <sul_a...@yahoo.co.in> writes:
>>>> When I am calling dsm_create on Linux using the POSIX DSM implementation 
>>>> can succeed, but result in SIGBUS when later try to access the memory.  
>>>> This happens because of my system does not have enough shm space &  
>>>> current allocation in dsm_impl_posix does not allocate disk blocks[1]. I 
>>>> wonder can we use fallocate system call (i.e. Zero-fill the file) to 
>>>> ensure that all the file space has really been allocated, so that we don't 
>>>> later seg fault when accessing the memory mapping. But here we will endup 
>>>> by loop calling ‘write’ squillions of times.
>>> Wouldn't that just result in a segfault during dsm_create?
>>> I think probably what you are describing here is kernel misbehavior
>>> akin to memory overcommit.  Maybe it *is* memory overcommit and can
>>> be turned off the same way.  If not, you have material for a kernel
>>> bug fix/enhancement request.
>> [...] But it
>> looks like if we used fallocate or posix_fallocate in the
>> dsm_impl_posix case we'd get a nice ESPC error, instead of
>> success-but-later-SIGBUS-on-access.
> Here's a simple test extension that creates jumbo dsm segments, and
> then accesses all pages.  If you ask it to write cheques that your
> Linux 3.10 machine can't cash on unpatched master, it does this:
> postgres=# create extension foo;
> postgres=# select test_dsm(16::bigint * 1024 * 1024 * 1024);
> server closed the connection unexpectedly
> ...
> LOG:  server process (PID 15105) was terminated by signal 7: Bus error
> If I apply the attached experimental patch I get:
> postgres=# select test_dsm(16::bigint * 1024 * 1024 * 1024);
> ERROR:  could not resize shared memory segment
> "/PostgreSQL.1938734921" to 17179869184 bytes: No space left on device
> It should probably be refactored a bit to separate the error messages
> for ftruncate and posix_fallocate, and we could possibly use the same
> approach for dsm_impl_mmap instead of that write() loop, but this at
> least demonstrates the problem Amul reported.  Thoughts?

Seems like it could be a reasonable change.  I wonder what happens on
other platforms.

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:

Reply via email to