Skip site navigation (1) Skip section navigation (2)

Re: time-delayed standbys

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: time-delayed standbys
Date: 2011-06-30 09:00:21
Message-ID: BANLkTi=nvWefCymUz8_mT_UK16trw-si6Q@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jun 30, 2011 at 2:56 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jun 29, 2011 at 9:54 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> I am not sure exactly how walreceiver handles it if the disk is full.
>>> I assume it craps out and eventually retries, so probably what will
>>> happen is that, after the standby's pg_xlog directory fills up,
>>> walreceiver will sit there and error out until replay advances enough
>>> to remove a WAL file and thus permit some more data to be streamed.
>>
>> Nope, it gets stuck and stops there.  Replay doesn't advance unless you
>> can somehow clear out some space manually; if the disk is full, the disk
>> is full, and PostgreSQL doesn't remove WAL files without being able to
>> write files first.
>>
>> Manual (or scripted) intervention is always necessary if you reach disk
>> 100% full.
>
> Wow, that's a pretty crappy failure mode... but I don't think we need
> to fix it just on account of this patch.  It would be nice to fix, of
> course.

How is that different to running out of space in the main database?

If I try to pour a pint of milk into a small cup, I don't blame the cup.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2011-06-30 09:47:34
Subject: Re: Latch implementation that wakes on postmaster death on both win32 and Unix
Previous:From: Hitoshi HaradaDate: 2011-06-30 08:37:43
Subject: Re: Parameterized aggregate subquery (was: Pull up aggregate subquery)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group