On 25.08.2011 19:11, Robert Haas wrote:
On Mon, Aug 22, 2011 at 2:57 AM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
So the problem is that walreceiver merrily writes so much future WAL that it
runs out of disk space? A limit on the maximum number of future WAL files to
stream ahead would fix that, but I can't get very excited about it. Usually
you do want to stream as much ahead as you can, to ensure that the WAL is
safely on disk on the standby, in case the master dies. So the limit would
need to be configurable.
It seems like perhaps what we really need is a way to make replaying
WAL (and getting rid of now-unneeded segments) to take priority over
getting new ones.
With the defaults we start to kill queries after a while that get in the
way of WAL replay. Daniel had specifically disabled that. Of course,
even with the query-killer disabled, it's possible for the WAL replay to
fall so badly behind that you fill the disk, so a backstop might be
useful anyway, although that seems a lot less likely in practice and if
your standby can't keep up you're in trouble anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
