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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
