Le jeudi 11 septembre 2008, Csaba Nagy a écrit : > Well now that I think I understand what Heikki meant, I also think the > problem is that there's no choice at all to advance, because the new > queries will simply have the same snapshot as currently running ones as > long as WAL reply is blocked... further blocking the WAL reply. When > saying this I suppose that the snapshot is in fact based on the last > recovered XID, and not on any slave-local XID. In that case once WAL > recovery is blocked, the snapshot is stalled too, further blocking WAL > recovery, and so on...
Well, it may be possible to instruct the WAL replay daemon to stop being polite sometimes: when a given max_lag_delay is reached, it could take locks and as soon as it obtains them, replay all remaining WAL. The max_lag_delay would be a GUC allowing to set the threshold between continuing the replay and running queries. There could some other nice ideas without inventing yet another GUC, but this one was eaiser to think about for me ;) -- dim
signature.asc
Description: This is a digitally signed message part.
