From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, slot ids and stuff |
Date: | 2009-01-09 11:23:35 |
Message-ID: | 496733B7.8040209@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Fri, 2009-01-09 at 12:33 +0200, Heikki Linnakangas wrote:
>> A related issue is that currently the recovery PANICs if it runs out of
>> recovery procs. I think that's not acceptable, regardless of whether we
>> use slotids or some other method to avoid it in normal operation,
>> because it means you can't recover at all if you set max_connections too
>> low in the standby (or in the primary, and you have to recover from
>> crash), or you run out of recovery procs because of an abort failed in
>> the primary like discussed on that thread.
>
>> The standby should just
>> fast-forward to the next running-xacts record in that case.
>
> What do you mean by "fast forward"?
I mean the standby should stop trying to track the in progress
transactions in recovery procs, and apply the WAL records like it does
before the consistent state is reached.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-01-09 11:49:57 | Re: Visibility map and freezing |
Previous Message | Simon Riggs | 2009-01-09 11:20:40 | Re: Hot standby, slot ids and stuff |