Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1GiY-0006E4-Cj for pgsql-admin@arkaria.postgresql.org; Wed, 17 Dec 2014 15:40:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Y1GiX-0002nq-Oj for pgsql-admin@arkaria.postgresql.org; Wed, 17 Dec 2014 15:40:49 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Y1GiW-0002nk-Qs for pgsql-admin@postgresql.org; Wed, 17 Dec 2014 15:40:49 +0000 Received: from mail-qc0-x229.google.com ([2607:f8b0:400d:c01::229]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Y1GiT-0006J0-6J for pgsql-admin@postgresql.org; Wed, 17 Dec 2014 15:40:46 +0000 Received: by mail-qc0-f169.google.com with SMTP id w7so12250129qcr.28 for ; Wed, 17 Dec 2014 07:40:44 -0800 (PST) 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:subject :content-type:content-transfer-encoding; bh=bvTj8jkIuuHEH4ULbQgGA3sjwdVxfTYBaFMCNOAYCkI=; b=XqMqNvoe5k63MgM2Y5k6S14cEiSSKLmnyubATDPJ8vRhUmUANLeD23XxZsBG2u7gbp 1kIP2RGxKLiGDCgU8L/Iho038sBbKSp4TnFIvKElKIGkV2lQzJxtZ8oCAZlL9Yn+awvd 1DYAsb1xFzr7DPoUz2Vv4MM3bxNGZeGxjjsIV8IdhOjD+LfTo2UfS3bBSxlvrrtrMMxp 4FPmWexSRqZXotB1/NlB2A0MRhFLCSAv/tk9vBKY7rwteX438dZHD+8dQwZMB7RYjl/E ORQ3BH6wiElzEokBX0FB451sYWDnR6b/K3FrOb/ayAl1mGZVFb7sPt9CtxMCASXzsV06 qwfg== X-Received: by 10.224.42.202 with SMTP id t10mr69741912qae.21.1418830844355; Wed, 17 Dec 2014 07:40:44 -0800 (PST) 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 l93sm4174077qge.6.2014.12.17.07.40.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 07:40:43 -0800 (PST) Message-ID: <5491A3F8.8000509@gmail.com> Date: Wed, 17 Dec 2014 10:40:40 -0500 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: "pgsql-admin@postgresql.org" Subject: Standby server startup question - not broken, just curious Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) 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 Hi all, I've got 3 PostgreSQL servers in a streaming standby configuration: 1 primary and 2 standby. These have been running great for a long time, and they are all running WAL archiving as an insurance policy to the stream. My questions relate to when any standby is started up, I always see in the logs that it tries to read a couple of WAL segments that should be present. What would happen if these weren't using WAL archiving - that is the primary wasn't sending them segments? How many segments is a standby usually looking for (I think I always see two)? I've also seen that if one of these segments is broken or malformed, that the standby errors on start and often fails to start. Could I just remove the segment causing the problem? After all with streaming working aren't WAL archives just superfluous? -- Jay -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin