From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | hlinnaka <hlinnaka(at)iki(dot)fi> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Venkata Balaji N <nag1010(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Borodin Vladimir <root(at)simply(dot)name>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming replication and WAL archive interactions |
Date: | 2015-05-13 12:36:09 |
Message-ID: | CA+Tgmoa9WQjBD4Nv1Tr-eYb93_Hemz9JmJdQdrja9ocnC24X-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 11, 2015 at 12:00 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-05-13 12:45:16 | Re: One question about security label command |
Previous Message | Stephen Frost | 2015-05-13 12:35:00 | Re: Default Roles |