On Sat, Jan 14, 2012 at 11:17 AM, Noah Misch <n...@leadboat.com> wrote: > On Sat, Jan 14, 2012 at 08:08:29AM +0000, Simon Riggs wrote: >> On Sat, Jan 14, 2012 at 1:02 AM, Noah Misch <n...@leadboat.com> wrote: >> > However, CLUSTER/VACUUM FULL already >> > remove tuples still-visible to standby snapshots without provoking a >> > recovery >> > conflict. ?(Again only with hot_standby_feedback=off.) >> >> If that were the case it would be a bug. >> >> CLUSTER/VACUUM FULL emit an AccessExclusiveLock record that would >> conflict with any current lock holders, so should be fine on that. > > I speak of this sequence (M = master connection, S = standby connection): > > M: CREATE TABLE t AS SELECT * FROM generate_series(1,1000) t(n); > S: BEGIN ISOLATION LEVEL REPEATABLE READ; SELECT 0; > M: DELETE FROM t WHERE n <= 10; > M: VACUUM FULL t; > S: SELECT count(*) FROM t; -- 990, should be 1000
OK, so we need to emit a heap_xlog_cleanup_info() record at the end of cluster to conflict with anybody that doesn't yet have a lock but has a snapshot that can see tuples the cluster implicitly removed. Will do. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
