Re: Hot Standby Feedback should default to on in 9.3+

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Kevin Grittner <kgrittn(at)mail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby Feedback should default to on in 9.3+
Date: 2012-11-30 21:53:43
Message-ID: CAGTBQpYCdC0uSNCohCn3xMUQ0j76V+LY-s2D3wdiGUivEXbYAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 30, 2012 at 6:49 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
>>> I have most certainly managed databases where holding up vacuuming
>>> on the source would cripple performance to the point that users
>>> would have demanded that any other process causing it must be
>>> immediately canceled. And canceling it wouldn't be enough at that
>>> point -- the bloat would still need to be fixed before they could
>>> work efficiently.
>>
>>
>> I wouldn't mind occasional cancels, but these were recurring. When a
>> query ran long enough, there was no way for it to finish, no matter
>> how many times you tried. The master never stops being busy, that's
>> probably a factor.
>
>
> Hmm, it sounds like max_standby_streaming_delay=1d didn't work as intended
> for some reason. It should've given the query one day to run before
> canceling it. Unless the standby was running one day behind the master
> already, but that seems unlikely. Any chance you could reproduce that?

I have a pre-production server with replication for these tests. I
could create a fake stream of writes on it, disable feedback, and see
what happens.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2012-11-30 22:07:23 Re: ALTER command reworks
Previous Message Heikki Linnakangas 2012-11-30 21:49:41 Re: Hot Standby Feedback should default to on in 9.3+