Re: (resolution?) Re: [HACKERS] memory problem again

Daniel Kalchev <daniel(at)digsys(dot)bg> writes:
> I found out how to resolve this problem, yet it does not explain why it
> happens anyway!
> I had postmaster started with this script:
> postmaster -D/usr/local/pgsql/data -B 256 -i -o "-e -S 8192" >>
> /usr/local/pgsql/errlog 2>&1 &
> Removing all the parameters to postmaster
> postmaster -D/usr/local/pgsql/data -i -o "-e" >> /usr/local/pgsql/errlog 2>&1 &
> made it work....
> Perhaps some memory management problem? I guess the -S option is the culprit
> here, but this machine has 256 MB RAM and actually never swaps (yet).

8192 * 1K = 8 meg workspace per sort sure doesn't sound unreasonable.
There is a sort going on under-the-hood in your SELECT DISTINCT (it's
implemented in the same fashion as "sort | uniq"), but under ordinary
circumstances that doesn't cause any problem. I can see a couple of
possibilities:
1. You have a very small kernel limit on per-process data space,
probably 8M or at most 16M.
2. Something is broken in the sort code that makes it fail to
obey the -S limit.
I favor #1, since if #2 were true we'd probably have noticed it before.

You might try experimenting with a couple of different -S values (-B
shouldn't make any difference here, it just affects the size of the
shared-memory-block request), and watching the size of the backend
process with top(1) or something like it.

In the meantime, find out where kernel parameters are set on your
system, and look at what MAXDSIZ is set to...

regards, tom lane