Re: Query error: could not resize shared memory segment

Hi,
Here is the result from host:

mount | grep /dev/shm
=> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

du -hs /dev/shm
=> 0 /dev/shm

df /dev/shm
=>
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 2023252 0 2023252 0% /dev/shm

----------------------------------------------------------------------
And here is the result from postgres container:

mount | grep /dev/shm
=> shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

du -hs /dev/shm
=> 8.0K /dev/shm

df /dev/shm
=>
Filesystem 1K-blocks Used Available Use% Mounted on
shm 65536 8 65528 1% /dev/shm

On Wed, Jan 3, 2018 at 12:05 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Jan 3, 2018 at 5:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
>>> So you have 16GB of RAM and here we're failing to posix_fallocate()
>>> 50MB (actually we can't tell if it's the ftruncate() or
>>> posix_fallocate() call that failed, but the latter seems more likely
>>> since the former just creates a big hole in the underlying tmpfs
>>> file). Can you share the query plan (EXPLAIN SELECT ...)?
>>
>> I wonder if OP is running with a tmpfs size setting that's less than
>> the traditional Linux default of half of physical RAM size.
>
> Hmm. Canh, can you please share the output of the following commands?
>
> mount | grep /dev/shm
> du -hs /dev/shm
> df /dev/shm
>
> --
> Thomas Munro
> http://www.enterprisedb.com