From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)mail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(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:40:27 |
Message-ID: | CAGTBQpb=yTM2BiByzzrP+1+hRtHM7jPeSKSZY7WYAmiAYFWcRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittner <kgrittn(at)mail(dot)com> wrote:
> Claudio Freire wrote:
>
>>> With what setting of max_standby_streaming_delay? I would rather
>>> default that to -1 than default hot_standby_feedback on. That
>>> way what you do on the standby only affects the standby.
>>
>> 1d
>
> Was there actually a transaction hanging open for an entire day on
> the standby? Was it a query which actually ran that long, or an
> ill-behaved user or piece of software?
No, and if there was, I wouldn't care for it to be cancelled.
Queries were being cancelled way before that timeout was reached,
probably something to do with max_keep_segments on the master side
being unable to keep up for that long.
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-11-30 21:45:18 | Re: initdb.c::main() too large |
Previous Message | Bruce Momjian | 2012-11-30 21:31:00 | Re: Further pg_upgrade analysis for many tables |