Re: Hot standby, slot ids and stuff

Simon Riggs wrote:
> On Fri, 2009-01-09 at 13:23 +0200, Heikki Linnakangas wrote:
>> 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.
> 
> ...
> 
> So, if we don't PANIC, how should we behave?
> 
> Without full information on running-xacts we would be unable to take a
> snapshot, so should:
> * backends be forcibly disconnected?
> * backends hang waiting for snapshot info to be re-available again in X
> minutes worth of WAL time?
> * backends throw an ERROR:  unable to provide snapshot at this time,
> DETAIL: retry your statement later. 
> ...other alternatives
> 
> and possibly prevent new connections.

All of those seem reasonable to me. The 2nd option seems nicest, "X 
minutes" should probably be controlled by max_standby_delay, after which 
you can throw an error.

If we care enough, we could also keep tracking the transactions in 
backend-private memory of the startup process, until there's enough room 
in proc array. That would make the outage shorter, because you wouldn't 
have to wait until the next running-xacts record, but only until enough 
transactions have finished that they all fit in proc array again.

But whatever is the simplest, really.

> If max_connections is higher on primary then the standby will *never* be
> available for querying. Should we have multiple ERRORs depending upon
> whether the situation is hopefully-temporary or looks-permanent?
> 
> Don't assume I want the PANIC. That clearly needs to be revisited if we
> change slotids. 

It needs to be revisited whether we change slotids or not, IMHO.

Note that with slotids, you have a problem as soon as any of the slots 
that don't exist on standby are used, regardless of how many concurrent 
transactions there actually is. Without slots you only have a problem if  you really have more than standby's
max_connectionsconcurrent 
 
transactions. That makes a big difference in practice.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com