On Thu, 2008-09-11 at 01:07 +0100, Simon Riggs wrote:
> Transaction snapshots is probably the most difficult problem for Hot
> Standby to resolve.
In summary of thread so far:
When queries on standby run for significantly longer than longest
queries on primary, some problems can occur. Various people have argued
for these responses to the problems:
1. Master uses Standby's OldestXmin
Effects:
* Long running queries on standby... Can delay row removal on primary Do not delay apply of WAL records on standby
* Queries on standby give consistent answers in all cases.
2. Master ignores Standby's OldestXmin
Effects:
* Long running queries on standby... Have no effect on primary Can delay apply of WAL records on standby
* Queries on standby give consistent answers in all cases.
3. Ignore problem
Effects:
* Long running queries on standby... Have no effect on primary Do not delay apply of WAL records on standby
* Queries on standby give inconsistent answers in some cases, though
doesn't generate any messages to show inconsistency occurred. Acceptable
for read-only and insert only tables only.
Hot Standby should provide all 3 responses as options.
(1) would be implemented by sending Standby OldestXmin to primary.
Snapshots would not be sent from primary, they will be derived locally
from transactions currently being applied.
(2) would be implemented by setting a timer. When Startup process has
waited for more than "redo_max_delay"/"max_lag_delay" (SIGHUP) we cancel
queries. If timeout is 0 we aggressively cancel queries without a
timeout.
(3) would be implemented using read_consistency = on (default) | off, a
USERSET parameter. When read_consistency = off we ignore the backend's
xmin when deciding whether to wait before applying WAL or not.
Summary OK for everyone?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support