Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYFjp-0001xJ-6q for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Aug 2016 16:55:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bYFjo-0002Ky-Pv for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Aug 2016 16:55:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bYFjn-0002Jd-Ta for pgsql-hackers@postgresql.org; Fri, 12 Aug 2016 16:55:16 +0000 Received: from nm20-vm6.bullet.mail.sg3.yahoo.com ([106.10.149.133]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bYFjj-0005sp-CJ for pgsql-hackers@postgresql.org; Fri, 12 Aug 2016 16:55:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s2048; t=1471020907; bh=7mdmFxCt0MaKZaeplmeo/YTfOXuzj4FFWkQe3L2MVMo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=iP+8a8viv1DQaeWBxqoNttnL9Ar/VhSxUMNzJ3/SaIf3mdUQNVydLUi3YPuInY85k/tspZnOYEVNJFePBcg8dmDCt+w/sq6ipOxiLgQRYmDHKqkV0Bf1reRSI2lzCAluxC87Mem1koLjoeyVJQF7vWF1D++2SfFTgPajXlN8CVaoW74Wd3oeiZmtgbgeYLFWcgWjwJA4PhtDvnoSXEQsjmgomIO8NCqffkwP38JC0F2Ab23v1ri5dmz98hih6ehQ6G7O/alds6TNKVrneCk7rnyg3tVzyTB9VcMGjnJJwOH5VHkpit2l8W2hRB4xKkJC1EA5jxtgpcgoNFZ5mIxXXw== Received: from [106.10.166.121] by nm20.bullet.mail.sg3.yahoo.com with NNFMP; 12 Aug 2016 16:55:07 -0000 Received: from [106.10.151.253] by tm10.bullet.mail.sg3.yahoo.com with NNFMP; 12 Aug 2016 16:55:07 -0000 Received: from [127.0.0.1] by omp1002.mail.sg3.yahoo.com with NNFMP; 12 Aug 2016 16:55:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 829144.81448.bm@omp1002.mail.sg3.yahoo.com Received: from jws10978.mail.sg3.yahoo.com by sendmailws105.mail.sg3.yahoo.com; Fri, 12 Aug 2016 16:55:07 +0000; 1471020907.464 Date: Fri, 12 Aug 2016 16:55:06 +0000 (UTC) From: amul sul Reply-To: "sul_amul@yahoo.co.in" To: Tom Lane Cc: PostgreSQL-development Message-ID: <1367880874.12379258.1471020906502.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <25838.1471010881@sss.pgh.pa.us> References: <1002664500.12301802.1471008223422.JavaMail.yahoo.ref@mail.yahoo.com> <1002664500.12301802.1471008223422.JavaMail.yahoo@mail.yahoo.com> <25838.1471010881@sss.pgh.pa.us> Subject: Re: Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create(). MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12379257_45065924.1471020906498" Content-Length: 5528 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org ------=_Part_12379257_45065924.1471020906498 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No segfault during dsm_create, =C2=A0mmap returns =C2=A0the memory address = =C2=A0which is inaccessible.=C2=A0 Let me see how can I disable kernel overcommit behaviour, but =C2=A0IMHO, = =C2=A0we should prevent ourselves from crashing, =C2=A0shouldn't we?=C2=A0 Regards, =C2=A0Amul--------------------------------------------------------= --------------------------------------------=C2=A0Sent from a mobile device= . Please excuse brevity and tpyos.=20 =20 On Fri, 12 Aug, 2016 at 7:38 pm, Tom Lane wrote: amu= l sul 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. =C2= =A0This happens because of my system does not have enough shm space & =C2= =A0current allocation in dsm_impl_posix does not allocate disk blocks[1].= =C2=A0I wonder can we use=C2=A0fallocate system call (i.e. Zero-fill the fi= le) to ensure that=C2=A0all the file space has really been allocated, so th= at we don't=C2=A0later seg fault when accessing the memory mapping. But=C2= =A0here we will endup by=C2=A0loop calling =E2=80=98write=E2=80=99=C2=A0squ= illions=C2=A0of 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.=C2=A0 Maybe it *is* memory overcommit and can be turned off the same way.=C2=A0 If not, you have material for a kernel bug fix/enhancement request. =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 regards, tom lane --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers =20 ------=_Part_12379257_45065924.1471020906498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No segfault during dsm_create,  mmap returns  = the memory address  which is inaccessible. 

Let= me see how can I disable kernel overcommit behaviour, but  IMHO, &nbs= p;we should prevent ourselves from crashing,  shouldn't we? 
<= /font>
Regards,  
Amul
= ---------------------------------------------------------------------------= ------------------------- 
Se= nt from a mobile device. Please excuse brevity and tpyos.

On Fri, 12 Aug, 2016 at 7:38 pm, Tom Lane<= /div>
<tgl@sss.pgh.pa.us> wrote:
=
amul = sul <sul_amul@yahoo.co.in> writes:

> When I am callin= g dsm_create on Linux using the POSIX DSM implementation can succeed, but r= esult in SIGBUS when later try to access the memory.  This happens bec= ause of my system does not have enough shm space &  current alloca= tion 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&= nbsp;all the file space has really been allocated, so that we don't la= ter seg fault when accessing the memory mapping. But here we will endu= p by loop calling =E2=80=98write=E2=80=99 squillions of time= s.


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 mater= ial for a kernel
bug fix/enhancement request.

          = ;  regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang= es to your subscription:
http://www.po= stgresql.org/mailpref/pgsql-hackers

------=_Part_12379257_45065924.1471020906498--