Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

2016-01-11 Thread Simon Riggs
On 11 January 2016 at 01:46, Robert Haas wrote: > /me crawls into a hole. > > Thanks. Far from it, thanks very much for thinking about it. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Serv

Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

2016-01-10 Thread Robert Haas
On Sun, Jan 10, 2016 at 3:50 PM, Simon Riggs wrote: > On 10 January 2016 at 16:32, Robert Haas wrote: >> >> On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs wrote: >> > Avoid pin scan for replay of XLOG_BTREE_VACUUM >> > Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to >> > re

Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

2016-01-10 Thread Simon Riggs
On 10 January 2016 at 16:32, Robert Haas wrote: > On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs wrote: > > Avoid pin scan for replay of XLOG_BTREE_VACUUM > > Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to > require > > complex interlocking that matched the requirements on

Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

2016-01-10 Thread Robert Haas
On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs wrote: > Avoid pin scan for replay of XLOG_BTREE_VACUUM > Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to > require > complex interlocking that matched the requirements on the master. This > required > an O(N) operation that be