Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Robert Haas
On Thu, Jul 7, 2016 at 5:26 AM, Simon Riggs wrote: > The behaviour of that function is defined in backbranches, so I suggest we > should not alter that now. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Simon Riggs
On 8 July 2016 at 00:43, Michael Paquier wrote: > On Thu, Jul 7, 2016 at 6:26 PM, Simon Riggs wrote: > > The behaviour of that function is defined in backbranches, so I suggest > we > > should not alter that now. > > Hm.. > > > What we can do is

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Michael Paquier
On Thu, Jul 7, 2016 at 6:26 PM, Simon Riggs wrote: > The behaviour of that function is defined in backbranches, so I suggest we > should not alter that now. Hm.. > What we can do is have another function that makes it clearer that the > answer is variable. >

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Simon Riggs
On 7 July 2016 at 08:26, Michael Paquier wrote: > On Thu, Jul 7, 2016 at 3:59 PM, Amit Langote > wrote: > > While reading the thread "BUG #14230: Wrong timeline returned by > > pg_stop_backup on a standby", I came to know that

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Kyotaro HORIGUCHI
Hello, At Thu, 07 Jul 2016 17:26:15 +0900, Kyotaro HORIGUCHI wrote in <20160707.172615.232806225.horiguchi.kyot...@lab.ntt.co.jp> > > As the result, this relaxation adds more good than bad and I > > agree to this. > > > > Addition to that, I'd like to propose

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Kyotaro HORIGUCHI
I wrote a bit wrong thing. At Thu, 07 Jul 2016 17:20:52 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160707.172052.213690356.horiguchi.kyot...@lab.ntt.co.jp> > > > To be honest, I have always found that this restriction was hard to > > > justify

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Kyotaro HORIGUCHI
At Thu, 7 Jul 2016 16:48:57 +0900, Amit Langote wrote in <3649f1e4-ac74-841e-6ae5-cfe0022aa...@lab.ntt.co.jp> > On 2016/07/07 16:26, Michael Paquier wrote: > > On Thu, Jul 7, 2016 at 3:59 PM, Amit Langote > > wrote: > >> While

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Amit Langote
On 2016/07/07 16:26, Michael Paquier wrote: > On Thu, Jul 7, 2016 at 3:59 PM, Amit Langote > wrote: >> While reading the thread "BUG #14230: Wrong timeline returned by >> pg_stop_backup on a standby", I came to know that ThisTimelineId is >> invalid on standby. And

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Michael Paquier
On Thu, Jul 7, 2016 at 3:59 PM, Amit Langote wrote: > While reading the thread "BUG #14230: Wrong timeline returned by > pg_stop_backup on a standby", I came to know that ThisTimelineId is > invalid on standby. And because pg_xlogfile_name_offset() uses the same >

Re: [HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-07-07 Thread Amit Langote
On 2016/05/19 17:34, Amit Langote wrote: > Currently in HEAD and 9.6, one can issue a non-exclusive backup on > standby, so this is OK: > > select pg_is_in_recovery(); > pg_is_in_recovery > --- > t > (1 row) > > select pg_start_backup('sby-bkp-test', 'f', 'f'); >

[HACKERS] pg_xlogfile_name_offset() et al and recovery

2016-05-19 Thread Amit Langote
Currently in HEAD and 9.6, one can issue a non-exclusive backup on standby, so this is OK: select pg_is_in_recovery(); pg_is_in_recovery --- t (1 row) select pg_start_backup('sby-bkp-test', 'f', 'f'); pg_start_backup - 0/5000220 (1 row) However the following