Re: [HACKERS] Proposal for changes to recovery.conf API

2017-09-05 Thread Michael Paquier
On Wed, Sep 6, 2017 at 12:31 AM, Simon Riggs wrote: > I've not worked on this at all, so it isn't ready for re-review and commit. > > I get the "lets do it early" thing and will try to extract a subset in > October. Nice to see that you are still planning to work on that.

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-09-05 Thread Simon Riggs
On 5 September 2017 at 06:47, Daniel Gustafsson wrote: >> On 27 Mar 2017, at 10:27, Simon Riggs wrote: >> >> On 7 March 2017 at 23:31, Josh Berkus wrote: >>> On 03/02/2017 07:13 AM, David Steele wrote: Hi Simon, On 2/25/17

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-09-05 Thread Daniel Gustafsson
> On 27 Mar 2017, at 10:27, Simon Riggs wrote: > > On 7 March 2017 at 23:31, Josh Berkus wrote: >> On 03/02/2017 07:13 AM, David Steele wrote: >>> Hi Simon, >>> >>> On 2/25/17 2:43 PM, Simon Riggs wrote: On 25 February 2017 at 13:58, Michael Paquier

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-03-28 Thread Michael Paquier
On Mon, Mar 27, 2017 at 5:27 PM, Simon Riggs wrote: > I share your pain, but there are various things about this patch that > make me uncomfortable. I believe we are looking for an improved design > not just a different design. > > I think the best time to commit such a

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-03-27 Thread Simon Riggs
On 7 March 2017 at 23:31, Josh Berkus wrote: > On 03/02/2017 07:13 AM, David Steele wrote: >> Hi Simon, >> >> On 2/25/17 2:43 PM, Simon Riggs wrote: >>> On 25 February 2017 at 13:58, Michael Paquier >>> wrote: >>> - trigger_file is removed.

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-03-07 Thread Josh Berkus
On 03/02/2017 07:13 AM, David Steele wrote: > Hi Simon, > > On 2/25/17 2:43 PM, Simon Riggs wrote: >> On 25 February 2017 at 13:58, Michael Paquier >> wrote: >> >>> - trigger_file is removed. >>> FWIW, my only complain is about the removal of trigger_file, this is >>>

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-03-02 Thread David Steele
Hi Simon, On 2/25/17 2:43 PM, Simon Riggs wrote: > On 25 February 2017 at 13:58, Michael Paquier > wrote: > >> - trigger_file is removed. >> FWIW, my only complain is about the removal of trigger_file, this is >> useful to detect a trigger file on a different

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-26 Thread Michael Paquier
On Sun, Feb 26, 2017 at 5:56 PM, Robert Haas wrote: > On Sat, Feb 25, 2017 at 7:28 PM, Michael Paquier > wrote: >> - pg_basebackup -R generates recovery.conf.auto. > > Does anything cause that file to get read? > > Wouldn't it be better to just

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-26 Thread Josh Berkus
On 02/26/2017 12:55 AM, Robert Haas wrote: > On Wed, Jan 11, 2017 at 11:23 PM, Simon Riggs wrote: >>> I think the issue was that some people didn't want configuration files >>> in the data directory. By removing recovery.conf we accomplish that. >>> Signal/trigger files

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-26 Thread Robert Haas
On Sat, Feb 25, 2017 at 7:28 PM, Michael Paquier wrote: > - pg_basebackup -R generates recovery.conf.auto. Does anything cause that file to get read? Wouldn't it be better to just append to postgresql.conf.auto? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-26 Thread Robert Haas
On Wed, Jan 11, 2017 at 11:23 PM, Simon Riggs wrote: >> I think the issue was that some people didn't want configuration files >> in the data directory. By removing recovery.conf we accomplish that. >> Signal/trigger files are not configuration (or at least it's much

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-25 Thread Simon Riggs
On 25 February 2017 at 13:58, Michael Paquier wrote: > - trigger_file is removed. > FWIW, my only complain is about the removal of trigger_file, this is > useful to detect a trigger file on a different partition that PGDATA! > Keeping it costs also nothing.. Sorry,

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-25 Thread Michael Paquier
On Fri, Feb 24, 2017 at 7:39 PM, Simon Riggs wrote: > New patch version implementing everything you requested, incl docs and > tap tests. The TAP changes look good to me. I thought that more diffs would have been necessary. > The patch as offered here is what I've been

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-02-24 Thread Simon Riggs
On 12 January 2017 at 13:34, Peter Eisentraut wrote: > On 1/11/17 5:27 AM, Simon Riggs wrote: >> The main area of "design doubt" remains the implementation of the >> recovery_target parameter set. Are we happy with the user interface >> choices in the patch,

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-12 Thread Fujii Masao
On Thu, Jan 12, 2017 at 6:46 PM, Simon Riggs wrote: > On 12 January 2017 at 05:49, Fujii Masao wrote: >> On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote: >>> On 11 January 2017 at 09:51, Fujii Masao

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-12 Thread Peter Eisentraut
On 1/11/17 5:27 AM, Simon Riggs wrote: > The main area of "design doubt" remains the implementation of the > recovery_target parameter set. Are we happy with the user interface > choices in the patch, given the understanding that the situation was > more comple than at first thought? Could you

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-12 Thread Simon Riggs
On 12 January 2017 at 05:49, Fujii Masao wrote: > On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote: >> On 11 January 2017 at 09:51, Fujii Masao wrote: >> 5. recovery.conf parameters are all moved to postgresql.conf,

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Fujii Masao
On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote: > On 11 January 2017 at 09:51, Fujii Masao wrote: > >>> 5. recovery.conf parameters are all moved to postgresql.conf, with these >>> changes >> >> In current design of the patch, when recovery

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Peter Eisentraut
On 1/11/17 12:53 PM, Simon Riggs wrote: >> I'm concerned that having signal files somewhere else opens up a bunch >> more edge cases that need to be considered. For example, what if >> someone puts a signal file into a temporary directory that is cleared >> after a server crash and restart. That

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Simon Riggs
Having already agreed to remove the two mentioned aspects, I'm just replying to fill in some historical details. On 11 January 2017 at 17:25, Peter Eisentraut wrote: > On 1/11/17 5:27 AM, Simon Riggs wrote: >> * Renaming primary_* parameters - Currently we use

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Peter Eisentraut
On 1/11/17 5:27 AM, Simon Riggs wrote: > * Renaming primary_* parameters - Currently we use this config setting > even when connecting to a standby, so the parameter is confusingly > named, so 10.0 is a good chance to name it correctly. Will submit as > separate patch. I don't subscribe to the

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Michael Paquier
On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote: > The specification of the recovery target parameters should be different, IMHO. > > If the user is performing a recovery and the target of the recovery is > incorrectly specified then it is clear that the recovery cannot

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Simon Riggs
On 11 January 2017 at 09:51, Fujii Masao wrote: >> 5. recovery.conf parameters are all moved to postgresql.conf, with these >> changes > > In current design of the patch, when recovery parameters are misconfigured > (e.g., set recovery_target_timeline to invalid timeline

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Simon Riggs
On 9 January 2017 at 19:50, Peter Eisentraut wrote: > On 1/1/17 4:14 PM, Simon Riggs wrote: >> OK, so here's the patch, plus doc cleanup patch. > > I don't think this patch is likely to succeed if we throw in more ideas > in every round. > > I think we have or

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Fujii Masao
On Tue, Jan 10, 2017 at 4:50 AM, Peter Eisentraut wrote: > On 1/1/17 4:14 PM, Simon Riggs wrote: >> OK, so here's the patch, plus doc cleanup patch. > > I don't think this patch is likely to succeed if we throw in more ideas > in every round. > > I think we have

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-11 Thread Fujii Masao
On Mon, Jan 2, 2017 at 6:14 AM, Simon Riggs wrote: > On 20 December 2016 at 15:11, Simon Riggs wrote: >> On 20 December 2016 at 15:03, Fujii Masao wrote: >> >>> API for crash recovery will never be changed. That is, crash

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-09 Thread Peter Eisentraut
On 1/1/17 4:14 PM, Simon Riggs wrote: > OK, so here's the patch, plus doc cleanup patch. I don't think this patch is likely to succeed if we throw in more ideas in every round. I think we have or are approaching agreement on moving recovery.conf into postgresql.conf, making the settings

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-03 Thread Josh Berkus
On 01/03/2017 08:47 AM, Robert Haas wrote: > On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs wrote: >> On 3 January 2017 at 15:50, Robert Haas wrote: >>> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote: Trying to fit

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-03 Thread Simon Riggs
On 3 January 2017 at 16:47, Robert Haas wrote: > On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs wrote: >> On 3 January 2017 at 15:50, Robert Haas wrote: >>> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-03 Thread Robert Haas
On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs wrote: > On 3 January 2017 at 15:50, Robert Haas wrote: >> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote: >>> Trying to fit recovery targets into one parameter was really not

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-03 Thread Simon Riggs
On 3 January 2017 at 15:50, Robert Haas wrote: > On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote: >> Trying to fit recovery targets into one parameter was really not >> feasible, though I tried. > > What was the problem? There are 5 different

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-03 Thread Robert Haas
On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote: > Trying to fit recovery targets into one parameter was really not > feasible, though I tried. What was the problem? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] Proposal for changes to recovery.conf API

2017-01-01 Thread Simon Riggs
On 20 December 2016 at 15:11, Simon Riggs wrote: > On 20 December 2016 at 15:03, Fujii Masao wrote: > >> API for crash recovery will never be changed. That is, crash recovery needs >> neither recovery.trigger nor standby.trigger. When the server

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-20 Thread Simon Riggs
On 20 December 2016 at 15:03, Fujii Masao wrote: > API for crash recovery will never be changed. That is, crash recovery needs > neither recovery.trigger nor standby.trigger. When the server starts a crash > recovery without any trigger file, any recovery parameter

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-20 Thread Fujii Masao
On Tue, Dec 20, 2016 at 7:11 AM, Simon Riggs wrote: > On 19 December 2016 at 21:29, Peter Eisentraut > wrote: >> On 12/16/16 8:52 PM, Robert Haas wrote: >>> If the explanation is just a few sentences long, I see no reason not >>> to

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-19 Thread Simon Riggs
On 19 December 2016 at 21:29, Peter Eisentraut wrote: > On 12/16/16 8:52 PM, Robert Haas wrote: >> If the explanation is just a few sentences long, I see no reason not >> to include it in the release notes. > > As far as I can tell from the latest posted patch,

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-19 Thread Peter Eisentraut
On 12/16/16 8:52 PM, Robert Haas wrote: > If the explanation is just a few sentences long, I see no reason not > to include it in the release notes. As far as I can tell from the latest posted patch, the upgrade instructions are - To trigger recovery, create an empty file recovery.trigger

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-18 Thread Bruce Momjian
On Sun, Dec 18, 2016 at 02:14:06PM +0100, Magnus Hagander wrote: > >     turn > >     > into another section that we keep around (whether as part of the > release > >     notes, > >     > or as a separate "upgrade steps" section or something). > > > >     I suggest

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-18 Thread Magnus Hagander
On Sun, Dec 18, 2016 at 2:11 PM, Bruce Momjian wrote: > On Sun, Dec 18, 2016 at 02:02:58PM +0100, Magnus Hagander wrote: > > > Again, I am fine putting this as a subsection of the release > notes, > > but > > > let's not pretend it is some extra section we

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-18 Thread Bruce Momjian
On Sun, Dec 18, 2016 at 02:02:58PM +0100, Magnus Hagander wrote: > >     Again, I am fine putting this as a subsection of the release notes, > but > >     let's not pretend it is some extra section we can remove in five > years. > > > > > > Depends on what we decide to

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-18 Thread Magnus Hagander
On Sun, Dec 18, 2016 at 1:57 PM, Bruce Momjian wrote: > On Sun, Dec 18, 2016 at 12:41:01PM +0100, Magnus Hagander wrote: > > No, they become uninteresting to anyone who has passed Postgres 10. > I > > would argue they are still required to be around even after we stop >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-18 Thread Bruce Momjian
On Sun, Dec 18, 2016 at 12:41:01PM +0100, Magnus Hagander wrote: > No, they become uninteresting to anyone who has passed Postgres 10.  I > would argue they are still required to be around even after we stop > supporting Postgres 9.6 because we know everyone will not upgrade off of >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-18 Thread Magnus Hagander
On Sat, Dec 17, 2016 at 10:34 PM, Bruce Momjian wrote: > On Sat, Dec 17, 2016 at 02:52:41PM +0100, Magnus Hagander wrote: > > The point is that the documentation about the recovery.conf changes > in > > Postgres are only interesting to people migrating to Postgres 10, >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-17 Thread Bruce Momjian
On Sat, Dec 17, 2016 at 02:52:41PM +0100, Magnus Hagander wrote: > The point is that the documentation about the recovery.conf changes in > Postgres are only interesting to people migrating to Postgres 10, i.e. > this is not quality documentation for someone going from Postgres 10 to >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-17 Thread Robert Haas
On Sat, Dec 17, 2016 at 8:52 AM, Magnus Hagander wrote: > On Sat, Dec 17, 2016 at 5:42 AM, Bruce Momjian wrote: >> On Fri, Dec 16, 2016 at 08:52:25PM -0500, Robert Haas wrote: >> > On Fri, Dec 16, 2016 at 8:07 PM, Tom Lane wrote: >> > >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-17 Thread Magnus Hagander
On Sat, Dec 17, 2016 at 5:42 AM, Bruce Momjian wrote: > On Fri, Dec 16, 2016 at 08:52:25PM -0500, Robert Haas wrote: > > On Fri, Dec 16, 2016 at 8:07 PM, Tom Lane wrote: > > > I'm still not seeing any value in putting this sort of info into > > > a

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-16 Thread Bruce Momjian
On Fri, Dec 16, 2016 at 08:52:25PM -0500, Robert Haas wrote: > On Fri, Dec 16, 2016 at 8:07 PM, Tom Lane wrote: > > I'm still not seeing any value in putting this sort of info into > > a documentation section that's distinct from the release notes. > > We've used links to wiki

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-16 Thread Robert Haas
On Fri, Dec 16, 2016 at 8:07 PM, Tom Lane wrote: > I'm still not seeing any value in putting this sort of info into > a documentation section that's distinct from the release notes. > We've used links to wiki pages in the past when the information > seemed to be in flux, and

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-16 Thread Tom Lane
Bruce Momjian writes: > On Fri, Dec 16, 2016 at 07:19:43PM -0500, Robert Haas wrote: >> I really don't see why we're resisting Josh's idea of putting a more >> complex set of migration instructions in the documentation someplace. >> Seems useful to me. Sure, we'd have to

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-16 Thread Bruce Momjian
On Fri, Dec 16, 2016 at 07:19:43PM -0500, Robert Haas wrote: > On Fri, Dec 16, 2016 at 5:29 PM, Bruce Momjian wrote: > > I am fine with the release note, or the release notes plus a link to a > > wiki, like we have done in the past with complex fixes in minor > > releases: > > >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-16 Thread Robert Haas
On Fri, Dec 16, 2016 at 5:29 PM, Bruce Momjian wrote: > I am fine with the release note, or the release notes plus a link to a > wiki, like we have done in the past with complex fixes in minor > releases: > > https://wiki.postgresql.org/wiki/20110408pg_upgrade_fix > > I

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-16 Thread Bruce Momjian
On Thu, Dec 15, 2016 at 04:16:36PM -0800, Josh Berkus wrote: > On 12/15/2016 12:54 PM, Tom Lane wrote: > > Magnus Hagander writes: > >> On Thu, Dec 15, 2016 at 1:11 AM, Bruce Momjian wrote: > >>> You are saying this is more massive than any other change we

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-15 Thread Josh Berkus
On 12/15/2016 12:54 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Thu, Dec 15, 2016 at 1:11 AM, Bruce Momjian wrote: >>> You are saying this is more massive than any other change we have made >>> in the past? In general, what need to be documented? >

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-15 Thread Tom Lane
Magnus Hagander writes: > On Thu, Dec 15, 2016 at 1:11 AM, Bruce Momjian wrote: >> You are saying this is more massive than any other change we have made >> in the past? In general, what need to be documented? > I don't necessarily think it's because it's

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-15 Thread Magnus Hagander
On Thu, Dec 15, 2016 at 1:11 AM, Bruce Momjian wrote: > On Wed, Dec 14, 2016 at 02:29:07PM -0800, Josh Berkus wrote: > > On 12/14/2016 08:06 AM, Bruce Momjian wrote: > > > On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: > > My own take on it is that the

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-14 Thread Bruce Momjian
On Wed, Dec 14, 2016 at 02:29:07PM -0800, Josh Berkus wrote: > On 12/14/2016 08:06 AM, Bruce Momjian wrote: > > On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: > My own take on it is that the release notes are already a massive > amount of work, and putting duplicative

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-14 Thread Josh Berkus
On 12/14/2016 08:06 AM, Bruce Momjian wrote: > On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: My own take on it is that the release notes are already a massive amount of work, and putting duplicative material in a bunch of other places isn't going to make things

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-14 Thread Bruce Momjian
On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: > >> My own take on it is that the release notes are already a massive > >> amount of work, and putting duplicative material in a bunch of other > >> places isn't going to make things better, it'll just increase the > >> maintenance

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-08 Thread Michael Paquier
On Fri, Dec 9, 2016 at 9:34 AM, Josh Berkus wrote: > On 12/08/2016 04:16 PM, Tom Lane wrote: >> Josh Berkus writes: >>> On 12/01/2016 05:58 PM, Magnus Hagander wrote: And in fairness, having such a "guide to changes" chapter in each release

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-08 Thread Josh Berkus
On 12/08/2016 04:16 PM, Tom Lane wrote: > Josh Berkus writes: >> On 12/01/2016 05:58 PM, Magnus Hagander wrote: >>> And in fairness, having such a "guide to changes" chapter in each >>> release probably *would* be a good idea. But it would take resources to >>> make that. The

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-08 Thread Tom Lane
Josh Berkus writes: > On 12/01/2016 05:58 PM, Magnus Hagander wrote: >> And in fairness, having such a "guide to changes" chapter in each >> release probably *would* be a good idea. But it would take resources to >> make that. The release notes are good, but having a more

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-08 Thread Josh Berkus
On 12/01/2016 05:58 PM, Magnus Hagander wrote: > >> * Add docs: "Guide to changes in recovery.conf in 10.0" > > > > Hmm, we don't usually write the docs in terms of how things are > > different from a previous version. Might seem strange in 5 years. > > Not sure what's best,

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-08 Thread Josh Berkus
On 12/04/2016 07:21 PM, Michael Paquier wrote: > On Mon, Dec 5, 2016 at 11:34 AM, Haribabu Kommi > wrote: >> As there was a feedback from others related to the patch and doesn't find >> any >> update from author. >> >> Closed in 2016-11 commitfest with "returned with

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-04 Thread Michael Paquier
On Mon, Dec 5, 2016 at 11:34 AM, Haribabu Kommi wrote: > As there was a feedback from others related to the patch and doesn't find > any > update from author. > > Closed in 2016-11 commitfest with "returned with feedback" status. > Please feel free to update the status

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-04 Thread Haribabu Kommi
On Fri, Dec 2, 2016 at 12:58 PM, Magnus Hagander wrote: > > As there was a feedback from others related to the patch and doesn't find any update from author. Closed in 2016-11 commitfest with "returned with feedback" status. Please feel free to update the status once you

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-01 Thread Magnus Hagander
On Fri, Dec 2, 2016 at 2:28 AM, Michael Paquier wrote: > On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas > wrote: > > On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs > wrote: > >> * pg_basebackup -R > >> will write

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-01 Thread Robert Haas
On Thu, Dec 1, 2016 at 8:28 PM, Michael Paquier wrote: > On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas wrote: >> On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs wrote: >>> * pg_basebackup -R >>> will write recovery.trigger to

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-01 Thread Michael Paquier
On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas wrote: > On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs wrote: >> * pg_basebackup -R >> will write recovery.trigger to data directory >> insert parameters postgresql.conf.auto, if possible > > Don't

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-01 Thread Robert Haas
On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs wrote: > * Move recovery.conf parameters into postgresql.conf > Allow reload of most parameters, allow ALTER SYSTEM > Provide visibility of values through GUC interface +1. > * recovery.conf is replaced by recovery.trigger ->

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-12-01 Thread Simon Riggs
On 29 November 2016 at 15:13, Simon Riggs wrote: > On 14 November 2016 at 15:50, Robert Haas wrote: >> On Sat, Nov 12, 2016 at 11:09 AM, Andres Freund wrote: >>> I'm very tempted to rename this during the move to GUCs >> ... >>>

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-29 Thread Simon Riggs
On 14 November 2016 at 15:50, Robert Haas wrote: > On Sat, Nov 12, 2016 at 11:09 AM, Andres Freund wrote: >> I'm very tempted to rename this during the move to GUCs > ... >> Slightly less so, but still tempted to also rename these. They're not >>

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-14 Thread Robert Haas
On Sat, Nov 12, 2016 at 11:09 AM, Andres Freund wrote: > I'm very tempted to rename this during the move to GUCs ... > Slightly less so, but still tempted to also rename these. They're not > actually necessarily pointing towards a primary, and namespace-wise > they're not

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-14 Thread Robert Haas
On Fri, Nov 4, 2016 at 10:17 AM, Abhijit Menon-Sen wrote: > At 2016-11-04 10:35:05 +, si...@2ndquadrant.com wrote: >> Since the "lots of parameters" approach is almost exactly what we have >> now, I think we should do that first, get this patch committed and >> then sit

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-12 Thread Andres Freund
Hi, On 2016-11-01 05:14:58 +0530, Abhijit Menon-Sen wrote: > Subject: Convert recovery.conf settings to GUCs I really want to get this in, we've been back and forth about this for far too long. > >- Create a recovery command file recovery.conf in the cluster >- data directory (see

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-04 Thread Abhijit Menon-Sen
At 2016-11-04 10:35:05 +, si...@2ndquadrant.com wrote: > > Since the "lots of parameters" approach is almost exactly what we have > now, I think we should do that first, get this patch committed and > then sit back and discuss an improved API and see what downsides it > introduces. Thanks, I

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-04 Thread Robert Haas
On Fri, Nov 4, 2016 at 6:04 AM, Michael Paquier wrote: > On Tue, Nov 1, 2016 at 11:31 PM, Robert Haas wrote: >> I liked Heikki's suggestion (at some point quite a while ago now) of >> recovery_target = 'xid 123' or recovery_target='lsn 0/723' or

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-04 Thread Simon Riggs
On 4 November 2016 at 10:04, Michael Paquier wrote: > On Tue, Nov 1, 2016 at 11:31 PM, Robert Haas wrote: >> I liked Heikki's suggestion (at some point quite a while ago now) of >> recovery_target = 'xid 123' or recovery_target='lsn 0/723' or >>

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-04 Thread Michael Paquier
On Tue, Nov 1, 2016 at 11:31 PM, Robert Haas wrote: > I liked Heikki's suggestion (at some point quite a while ago now) of > recovery_target = 'xid 123' or recovery_target='lsn 0/723' or > whatever. My vote goes for having two separate parameters, because as we know that

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-11-01 Thread Robert Haas
On Mon, Oct 31, 2016 at 7:44 PM, Abhijit Menon-Sen wrote: > At 2016-09-28 13:13:56 -0400, robertmh...@gmail.com wrote: I hope that the fact that there's been no discussion for the last >> three weeks doesn't mean this effort is dead; I would like very >> much to see it

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-10-31 Thread Abhijit Menon-Sen
At 2016-09-28 13:13:56 -0400, robertmh...@gmail.com wrote: > > I hope that the fact that there's been no discussion for the last > three weeks doesn't mean this effort is dead; I would like very > much to see it move forward. Here's an updated patch. Sorry, I got busy elswhere. I struggled with

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-10-21 Thread Josh Berkus
On 09/28/2016 10:13 AM, Robert Haas wrote: > On Tue, Sep 6, 2016 at 10:11 AM, David Steele wrote: >> On 9/6/16 8:07 AM, Robert Haas wrote: >>> On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs >>> wrote: Related cleanup * Promotion signal file is

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-28 Thread Robert Haas
On Tue, Sep 6, 2016 at 10:11 AM, David Steele wrote: > On 9/6/16 8:07 AM, Robert Haas wrote: >> On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs >> wrote: >>> Related cleanup >>> * Promotion signal file is now called "promote.trigger" rather than >>> just

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread David Steele
On 9/6/16 8:07 AM, Robert Haas wrote: On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs wrote: > Related cleanup * Promotion signal file is now called "promote.trigger" rather than just "promote" * Remove user configurable "trigger_file" mechanism - use "promote.trigger"

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Michael Paquier
On Tue, Sep 6, 2016 at 10:01 PM, Petr Jelinek wrote: > That's also reasonable solution, I don't really have preference between > those. My main point was to get rid of the 5 or so variables where only one > will actually be used in the end. And no need to worry about the

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Petr Jelinek
On 06/09/16 13:52, David Steele wrote: On 9/6/16 4:56 AM, Petr Jelinek wrote: On 06/09/16 07:18, Abhijit Menon-Sen wrote: Do we want something like this (easy to implement and document, perhaps not especially convenient to use): recovery_target = 'xid' # or

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Robert Haas
On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs wrote: > This is a summary of proposed changes to the recovery.conf API for > v10. These are based in part on earlier discussions, and represent a > minimal modification to current usage. This looks great. > Proposed changes

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread David Steele
On 9/6/16 4:56 AM, Petr Jelinek wrote: On 06/09/16 07:18, Abhijit Menon-Sen wrote: Do we want something like this (easy to implement and document, perhaps not especially convenient to use): recovery_target = 'xid' # or 'time'/'name'/'lsn'/'immediate' recovery_target_xid = xxx? #

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Abhijit Menon-Sen
At 2016-09-06 10:56:53 +0200, p...@2ndquadrant.com wrote: > > So +1 on the recovery_target = 'xid:xxx' idea. OK, I'll make it work that way. New patch in a couple of days. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Petr Jelinek
On 06/09/16 07:18, Abhijit Menon-Sen wrote: One open issue is the various assign_recovery_target_xxx functions, which Michael noted in his earlier review: +static void +assign_recovery_target_xid(const char *newval, void *extra) +{ + recovery_target_xid = *((TransactionId *) extra); + +

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Simon Riggs
On 6 September 2016 at 08:06, Abhijit Menon-Sen wrote: > At 2016-09-06 14:40:54 +0900, michael.paqu...@gmail.com wrote: >> >> my best advice here is to make all those recovery_target_* parameters >> PGC_POSTMASTER so as they are loaded only once when the server starts, >>

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-06 Thread Abhijit Menon-Sen
At 2016-09-06 14:40:54 +0900, michael.paqu...@gmail.com wrote: > > my best advice here is to make all those recovery_target_* parameters > PGC_POSTMASTER so as they are loaded only once when the server starts, > and then we define the recovery target type used in the startup > process instead of

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-05 Thread Michael Paquier
On Tue, Sep 6, 2016 at 2:18 PM, Abhijit Menon-Sen wrote: > One open issue is the various assign_recovery_target_xxx functions, > which Michael noted in his earlier review: > [...] > I don't like this code, but I'm not yet sure what to replace it with. I > think we should

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-05 Thread Abhijit Menon-Sen
Hi. Here's an updated version of my patch, which now applies on top of the patch that Simon posted earlier (recovery_startup_r10_api.v1b.patch). A few notes: 1. I merged in recovery_target_lsn as a new GUC setting. 2. I fixed various minor nits in the earlier patch, not worth mentioning

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-01 Thread Simon Riggs
On 31 August 2016 at 20:01, Abhijit Menon-Sen wrote: > Unfortunately, some parts conflict with the patch that Simon just posted > (e.g., his patch removes trigger_file altogether, whereas mine converts > it into a GUC along the lines of the original patch). Rather than

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-01 Thread Simon Riggs
On 1 September 2016 at 06:34, Michael Paquier wrote: > On Thu, Sep 1, 2016 at 1:15 AM, Simon Riggs wrote: >> This is a summary of proposed changes to the recovery.conf API for >> v10. These are based in part on earlier discussions, and represent

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-01 Thread Abhijit Menon-Sen
At 2016-09-01 15:51:11 +0900, michael.paqu...@gmail.com wrote: > > - (errmsg("starting point-in-time recovery to XID %u", > - recoveryTargetXid))); > User loses information if those logs are removed. Agreed. I'm revising the patch right now, and I

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-01 Thread Michael Paquier
On Thu, Sep 1, 2016 at 4:01 AM, Abhijit Menon-Sen wrote: > At 2016-08-31 17:15:59 +0100, si...@2ndquadrant.com wrote: >> >> * Recovery parameters would now be part of the main postgresql.conf >> infrastructure >> Any parameters set in $DATADIR/recovery.conf will be read

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-09-01 Thread Michael Banck
On Wed, Aug 31, 2016 at 05:15:59PM +0100, Simon Riggs wrote: > Recover mode starts the server as a standby server which > expects to receive changes from a primary/master server using physical > streaming replication or is used for performing a recovery from > backup. I understand where this is

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-08-31 Thread Michael Paquier
On Thu, Sep 1, 2016 at 1:15 AM, Simon Riggs wrote: > This is a summary of proposed changes to the recovery.conf API for > v10. These are based in part on earlier discussions, and represent a > minimal modification to current usage. > > Proposed changes (with reference to

Re: [HACKERS] Proposal for changes to recovery.conf API

2016-08-31 Thread Abhijit Menon-Sen
At 2016-08-31 17:15:59 +0100, si...@2ndquadrant.com wrote: > > * Recovery parameters would now be part of the main postgresql.conf > infrastructure > Any parameters set in $DATADIR/recovery.conf will be read after the > main parameter file, similar to the way that postgresql.conf.auto is > read. >

  1   2   >