From owner-freebsd-stable@FreeBSD.ORG Wed Jun 29 18:59:49 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2C3116A41F for ; Wed, 29 Jun 2005 18:59:49 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B73843D55 for ; Wed, 29 Jun 2005 18:59:49 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.148] (host-148.int.kcilink.com [192.168.7.148]) by yertle.kcilink.com (Postfix) with ESMTP id A5C99B862; Wed, 29 Jun 2005 14:59:48 -0400 (EDT) In-Reply-To: <1120050088.19603.7.camel@lanshark.dmv.com> References: <1120050088.19603.7.camel@lanshark.dmv.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58067976-00C6-4380-90DF-F448D9008C81@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Wed, 29 Jun 2005 14:59:46 -0400 To: postgres general X-Mailer: Apple Mail (2.730) Cc: stable@freebsd.org Subject: Re: PostgreSQL's vacuumdb fails to allocate memory for non-root users X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2005 18:59:49 -0000 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.