Re: Disabled features on Hot Standby
От | Simon Riggs |
---|---|
Тема | Re: Disabled features on Hot Standby |
Дата | |
Msg-id | CA+U5nM+AajL=MYEYq6LZJT9-wnfxZA71CeCKiS_PP1PU2ZgwXA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Disabled features on Hot Standby (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
On Sat, Jan 14, 2012 at 11:17 AM, Noah Misch <noah@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 <noah@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
В списке pgsql-hackers по дате отправления: