Date: Wed, 29 Jun 2005 16:19:01 -0400 From: Sven Willenberger <sven@dmv.com> To: Juergen.Dankoweit@T-Online.de Cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL's vacuumdb fails to allocate memory for non-root users Message-ID: <1120076341.19611.74.camel@lanshark.dmv.com> In-Reply-To: <1120074873.1720.3.camel@primergy470.juergendankoweit.net> References: <1120050088.19603.7.camel@lanshark.dmv.com> <58067976-00C6-4380-90DF-F448D9008C81@khera.org> <1120074873.1720.3.camel@primergy470.juergendankoweit.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2005-06-29 at 21:54 +0200, Juergen Dankoweit wrote: > Hello, > > Am Mittwoch, den 29.06.2005, 14:59 -0400 schrieb Vivek Khera: > > On Jun 29, 2005, at 9:01 AM, Sven Willenberger wrote: > > > > > Unix user root (and any psql superuser) the vacuum runs fine. It is > > > when > > > the unix user is non-root (e.g. su -l pgsql -c "vacuumdb -a -z") that > > > this memory error occurs. All users use the "default" class for > > > login.conf purposes which has not been modified from its installed > > > settings. Any ideas on how to a) troubleshoot this or b) fix this > > > (if it > > > is something obvious that I just cannot see). > > > > This doesn't make sense: the actual command is executed by the > > backend postgres server, so the uid of the client program doens't > > make a bit of difference. > > > > You need to see exactly who is generating that error. It certainly > > is not the Pg backend. > > Sorry for that possible stupid question. But why do you think that the > PG backend does not generate the error? > I use PostgreSQL since many years under FreeBSD and it is the first time > to hear from such an error. As the postgres logfiles have the out of memory error in them it would appear that it is the backend generating this error. Since, I am assuming here, dfldsiz and maxdsiz (set in loader.conf at 850MB and 1G respectively)) are per process, and since I have maintenance work_mem set at 512M (this all on a 3G box) I am not sure how it fails to allocate the memory; although top reports only 25-30MB free, there is some 2.5G in Inactive so there is plenty of memory available. I am currently running memtest to see if I may have flaky RAM ... Sven
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1120076341.19611.74.camel>