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. I would
suggest to move
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 2:43 PM, Simon Riggs wrote:
> On 25 February 2017 at 1
> 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
wrote:
> - trigger_file
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 patch is at the beginning o
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.
FWIW, my only complain is about the removal o
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
>>> useful to detect a trigger
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 partition that PGDATA!
>> Keeping i
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 append to postgresql.conf.auto?
Yeah, that would be
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 are not configuration (or
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: http://www.enterprisedb.com
The Enterprise PostgreSQL
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 easier
>> to argue that), so
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, that is just an error of imple
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 asked to do by everybody
>
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, given the understanding that the situat
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 wrote:
>>>
> 5. recovery.conf parameters are all moved to postgresql.conf, with these
>>
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 sum
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, with these
changes
>>>
>>> In current design of the patch, when rec
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 parameters are misconfigured
>> (e.g., set recovery
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
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 this config setting
>> even when con
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 ide
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
> continue with an impre
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 id) and
> the configurat
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 are approaching agreement on moving r
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 or are approaching agreement on mov
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 recovery needs
>>> neither recovery.trigger nor standby.trigger. When the
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 reloadabl
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 recovery targets into one parameter was really not
feasible, though I
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 wrote:
Trying to fit recovery targets into one parameter was really not
feasible, thou
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
>>> feasible, though I tried.
>>
>> What was the problem?
>
> There are
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 parameters that affect the recovery target, 3 of
wh
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 via pgsql-hackers mailing
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 starts a crash
>> recovery without any trigger file
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 settings in
> postgresql.conf a
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 include it in the release notes.
>>
>> As far as I can tell from
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, the upgrade
> instructions are
>
> -
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 instead
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 whate
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 can remove in
> five
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 d
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
> > supporting P
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
>
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,
> i.e.
> > this
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
>
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:
>> > > I'm still not seeing any value in putting this sort of info
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 documentation section that's distinct from the
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 pages in the past wh
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 that's reasonable. Bu
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 "carry" it forever, but w
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:
> >
> > https://
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 think what we _don'
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 have made
> >>> in the past? In general
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?
>
>> I don't necessarily think it's beca
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 more massive than any chance we
> have
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 release notes are alr
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 ma
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 bet
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 b
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 probably *would* be a good idea. But it would
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 release notes are goo
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 hand-holding
>> version e
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, he
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 feedback" status.
>> Please fe
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 once you submit the updated
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 submit the updated patch
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 recovery.trigger to data directory
> >> insert parameters postgresql.conf.auto, if poss
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 data directory
>>> insert parameters postgresql.conf.auto, if possible
>>
>
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 understand that last line; otherwise, +1.
pg_basebackup
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 -> recovery.done
+1.
> *
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
>> ...
>>> Slightly less so, but still tempted to also rename these. They're n
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
>> actually necessarily pointing towards a primary, a
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 grouped with recovery_*,
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 back and discuss an imp
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 )
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 a
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
>> whatever.
>
> My vote goes for having two separa
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
>> whatever.
>
> My vote goes for having two separate
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 there will be always two
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 move forward.
>
> Here'
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 t
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 now called "promote.trigger" rather than
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 "promote"
>>> * Remove user configurable "tri
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" for all cases
I'm in fav
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 priority of the target ty
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 'time'/'name'/'lsn'/'immedi
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 (with reference to patches
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? # t
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:
htt
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);
+
+
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,
>> and then we define the re
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 tr
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 address the underlying pro
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
indiv
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 trying
> to untangle that r
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 a
>> minimal modification to current usage.
>>
>> P
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 decide
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 after the
>> main parameter
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 c
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 patches from Abhijit Menon
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.
>
100 matches
Mail list logo
