Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YsVtY-0005CV-Gd for pgsql-hackers@arkaria.postgresql.org; Wed, 13 May 2015 12:36:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YsVtY-0000Aj-0j for pgsql-hackers@arkaria.postgresql.org; Wed, 13 May 2015 12:36:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YsVtW-00008b-0T for pgsql-hackers@postgresql.org; Wed, 13 May 2015 12:36:14 +0000 Received: from mail-qc0-x22b.google.com ([2607:f8b0:400d:c01::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1YsVtT-0007Vw-9I for pgsql-hackers@postgresql.org; Wed, 13 May 2015 12:36:12 +0000 Received: by qcbgu10 with SMTP id gu10so21180364qcb.2 for ; Wed, 13 May 2015 05:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KMCLBL7DiJFH2OOV4ZAEx5GfXY3d6FigWHS4RfprxO4=; b=xzpQGkjyMlK169A0PToPqLock3hGdLPfFbYJ2rdAuNJz2gh0OlFmCDbJSYe+D1Svd+ vP8hI39GYxwRNV3cpGFP6ICmvJi/CxkfdCTSXiDd9D90D3QG2DvfZu/A/ZLUh2DJ+yNO C44vGDobk14w9QfbThxeZ2BLzPWyCZxas9thJCAx9E5sAdLi8fb9L9U32tbFbbbwEq2M qyjkHrTf4E02aU7rbdSrDXn3gRZ7hwBKbzjKFWON1ltbtGyJt2NK0euTQyoL8414Y5F4 cOmInlFci4CM5lwJSKTTS91LNAKC9/iRQHcK7Gr/laqPLkKPL9ltwDQsXOEb3l571zO4 Uy8g== MIME-Version: 1.0 X-Received: by 10.140.233.140 with SMTP id e134mr27605253qhc.63.1431520570126; Wed, 13 May 2015 05:36:10 -0700 (PDT) Received: by 10.140.250.139 with HTTP; Wed, 13 May 2015 05:36:09 -0700 (PDT) In-Reply-To: <5550D20D.6090703@iki.fi> References: <548AF1CB.80702@vmware.com> <689EB259-44C2-4820-B901-4F6B1C55A1E4@simply.name> <549083D6.1000301@vmware.com> <54949108.3030109@vmware.com> <552FA38F.9060005@iki.fi> <5535FE71.1010905@iki.fi> <55362CAD.2000207@iki.fi> <553741FE.1080403@iki.fi> <554CB84E.3070406@iki.fi> <5550D20D.6090703@iki.fi> Date: Wed, 13 May 2015 08:36:09 -0400 Message-ID: Subject: Re: Streaming replication and WAL archive interactions From: Robert Haas To: hlinnaka Cc: Michael Paquier , Venkata Balaji N , Andres Freund , Fujii Masao , Borodin Vladimir , PostgreSQL-development Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On Mon, May 11, 2015 at 12:00 PM, Heikki Linnakangas wrote: > And here is a new version of the patch. I kept the approach of using pgstat, > but it now only polls pgstat every 10 seconds, and doesn't block to wait for > updated stats. It's not entirely a new problem, but this error message has gotten pretty crazy: + (errmsg("WAL archival (archive_mode=on/always/shared) requires wal_level \"archive\", \"hot_standby\", or \"logical\""))); Maybe: WAL archival cannot be enabled when wal_level is "minimal" I think the documentation should be explicit about what happens if the primary archives a file and dies before the standby gets notified that the archiving happened. The standby, running in shared mode, is then promoted. My first guess would be that the standby will end up with files that thinks it needs to archive but, being unable to do so because they're already there, they'll live forever in pg_xlog. I hope that's not the case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers