Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XjXHB-000748-Ii for pgsql-admin@arkaria.postgresql.org; Wed, 29 Oct 2014 17:43:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XjXHA-0006ro-UE for pgsql-admin@arkaria.postgresql.org; Wed, 29 Oct 2014 17:43:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XjXHA-0006ri-5G for pgsql-admin@postgresql.org; Wed, 29 Oct 2014 17:43:16 +0000 Received: from mail-yk0-x22c.google.com ([2607:f8b0:4002:c07::22c]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XjXH6-0002nc-F5 for pgsql-admin@postgresql.org; Wed, 29 Oct 2014 17:43:15 +0000 Received: by mail-yk0-f172.google.com with SMTP id q9so1523579ykb.3 for ; Wed, 29 Oct 2014 10:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=q7d/EYemjI45njSknaCkVv9LF3+e+pPkKjG9RrUWt6E=; b=QNSDhaXloioiPwCuZsgZkNPMWyAlbLTVJiS/+U89ar097GZ5BkcgnkJwxUXZk9jhcT VERrq7eXBrArExcTbD5KDSbEGQUHpSsm6YtnBqGK8mbUMy8szop50VLCsr6bPS6qAqaE Kz7JuCMtGw5GjvsO9E2RO0GcV0SP0d2fS+Pv2n0KouyqsSNsvr5wJqvGvWiJFBY5CjZ+ bVn7S3vTLDWhBoDPs8sdom14H7dh31X6S+Xw28rcNlKPAhX7/4w1OySSHMIwQgmo5uYh FOSZ86MpSEaRd4GepqSNQ5UTYxkD/Dsydv1t3TQddYXUIXUvqAh6ckjBTNmvM0ejBvEq VSsA== X-Received: by 10.170.141.2 with SMTP id i2mr4689049ykc.16.1414604590018; Wed, 29 Oct 2014 10:43:10 -0700 (PDT) Received: from [192.168.254.2] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id m28sm2196939yhb.50.2014.10.29.10.43.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 10:43:09 -0700 (PDT) Message-ID: <545126F0.2090704@gmail.com> Date: Wed, 29 Oct 2014 13:42:08 -0400 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Lane CC: Shreeyansh dba , "pgsql-admin@postgresql.org" Subject: Re: A local replication entry References: <5450E937.2070408@gmail.com> <5450FB3D.7030008@gmail.com> <23872.1414595142@sss.pgh.pa.us> <54510950.90100@gmail.com> <25754.1414599609@sss.pgh.pa.us> In-Reply-To: <25754.1414599609@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Well, it is using the pg_hba.conf I thought. I edited the pg_hba.conf file and changed the line I thought pg_basebackup should be using from "trust" to "fake_it" and issued a reload. I saw an "invalid authentication method 'fake_it'" reported in the pg_log/postgresql-Wed.log file. To confirm that it really was using the correct pg_hba.conf file and I stopped the database and tried to start it again. That start did fail with: % LOG: invalid authentication method "fake_it" % CONTEXT: line 101 of configuration file "/var/lib/pgsql/9.3/data/pg_hba.conf" % FATAL: could not load pg_hba.conf So, it really is using the correct pg_hba.conf. Allow me to note, in closing, that this particular VM: csgha2 has been a problem child since it was built, and many things have been broken on it. I don't know if this is another one of the very hard-to-solve problems or not. I may try this on another of my sandbox systems. Still I need to know why this is failing. On 10/29/2014 12:20 PM, Tom Lane wrote: > John Scalia writes: >> I thought you might be correct, Tom, but I double-checked the postgresql.conf file and listen_addresses = "*". I had forgotten to look to see if netstat reported: >> tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN >> But even with that established, the pg_basebackup using: >> /usr/pgsql-9.3/bin/pg_basebackup -D - -h 127.0.0.1 -Ft -z -c fast -l hourly.backup > backup_file.gz or >> /usr/pgsql-9.3/bin/pg_basebackup -D - -h 127.0.0.1 -U postgres -Ft -z -c fast -l hourly.backup > backup_file.gz >> are still failing with: >> pg_basebackup: could not connect to server: FATAL: no pg_hba.conf entry for replication connection from host "127.0.0.1", user "postgres", SSL off >> The line from the pg_hba.conf file currently reads: >> host replication postgres 127.0.0.1/32 trust >> I really don't see where the problem is, and I know I've done a reload after every change in the pg-hba.conf. > Everything that you've said looks fine, so the problem is somewhere you're > not looking :-(. At this point, I'd wonder if the pg_hba.conf file you're > changing is the same one the postmaster is reading. You might try > confirming that directly by inserting a syntactically-incorrect entry and > seeing if the postmaster bleats about it to the postmaster log when you > issue a reload. > > regards, tom lane > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin