X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id EDC1F53E10 for ; Thu, 5 May 2005 15:06:44 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14420-04 for ; Thu, 5 May 2005 18:06:40 +0000 (GMT) Received: from www.roaringpenguin.com (www.roaringpenguin.com [206.191.13.82]) by svr1.postgresql.org (Postfix) with ESMTP id AB4A853DF7 for ; Thu, 5 May 2005 15:06:38 -0300 (ADT) Received: from hydrogen.roaringpenguin.com (ottawa-hs-64-26-171-99.s-ip.magma.ca [64.26.171.99]) by www.roaringpenguin.com (8.13.4/8.13.1) with ESMTP id j45I6ZVd003616; Thu, 5 May 2005 14:06:35 -0400 Received: from [192.168.10.1] (hydrogen.roaringpenguin.com [192.168.10.1]) by hydrogen.roaringpenguin.com (8.12.8/8.12.8) with ESMTP id j45I6X2R006102; Thu, 5 May 2005 14:06:33 -0400 Message-ID: <427A60A9.7080309@roaringpenguin.com> Date: Thu, 05 May 2005 14:06:33 -0400 From: "David F. Skoll" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-admin@postgresql.org Cc: Alvaro Herrera Subject: Re: A real puzzler: ANY way to recover? References: <427A5472.8060004@roaringpenguin.com> <20050505174936.GA19346@dcc.uchile.cl> In-Reply-To: <20050505174936.GA19346@dcc.uchile.cl> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 206.191.13.82 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200505/53 X-Sequence-Number: 17482 Alvaro Herrera wrote: > Connect in standalone mode? Does not work. Tom Lane replied with the only thing that does work, which we independently discovered about 30 seconds before hearing from Tom. :-) The solution is to modify the PostgreSQL source code to skip the check, and run the modified binary in standalone mode just to reset the datallowconn flag to true. Once we did that, we quit and started the normal server to complete the maintenance work. I recommend having a postgres single-user-mode command-line option to disable the check, with a suitably stern warning in the man page not to use it. :-) Regards, David.