On Sat, Feb 21, 2015 at 6:45 AM, Peter Eisentraut wrote:
> On 2/19/15 4:33 PM, Josh Berkus wrote:
>> On 02/19/2015 12:23 PM, Peter Eisentraut wrote:
>>> On 1/6/15 4:22 PM, Peter Eisentraut wrote:
That said, there is a much simpler way to achieve that specific
functionality: Expose all th
On 2/19/15 4:33 PM, Josh Berkus wrote:
> On 02/19/2015 12:23 PM, Peter Eisentraut wrote:
>> On 1/6/15 4:22 PM, Peter Eisentraut wrote:
>>> That said, there is a much simpler way to achieve that specific
>>> functionality: Expose all the recovery settings as fake read-only GUC
>>> variables. See at
On 02/19/2015 12:23 PM, Peter Eisentraut wrote:
> On 1/6/15 4:22 PM, Peter Eisentraut wrote:
>> That said, there is a much simpler way to achieve that specific
>> functionality: Expose all the recovery settings as fake read-only GUC
>> variables. See attached patch for an example.
>
> The commit
On 1/6/15 4:22 PM, Peter Eisentraut wrote:
> That said, there is a much simpler way to achieve that specific
> functionality: Expose all the recovery settings as fake read-only GUC
> variables. See attached patch for an example.
The commit fest app has this as the patch of record. I don't think
On 2015-01-16 21:50:16 +0900, Michael Paquier wrote:
> On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund wrote:
> > On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
> >> On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote:
> >> > I have written similar logic, and while it's not pleasant, it's
On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund wrote:
> On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
>> On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote:
>> > I have written similar logic, and while it's not pleasant, it's doable.
>> > This issue would really only go away if you do
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
> On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote:
> > I have written similar logic, and while it's not pleasant, it's doable.
> > This issue would really only go away if you don't use a file to signal
> > recovery at all, which you have
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote:
> I have written similar logic, and while it's not pleasant, it's doable.
> This issue would really only go away if you don't use a file to signal
> recovery at all, which you have argued for, but which is really a
> separate and more diffic
On 01/15/2015 02:24 AM, Robert Haas wrote:
> I think your idea of adding read-only GUCs with the same names as all
> of the recovey.conf parameters is a clear win. Even if we do nothing
> more than that, it makes the values visible from the SQL level, and
> that's good. But I think we should go f
On 14/01/15 14:24, Robert Haas wrote:
On Mon, Jan 5, 2015 at 8:43 PM, Peter Eisentraut wrote:
I have previously argued for a different approach: Ready recovery.conf
as a configuration file after postgresql.conf, but keep it as a file to
start recovery. That doesn't break any old workflows, it
On Mon, Jan 5, 2015 at 8:43 PM, Peter Eisentraut wrote:
> I have previously argued for a different approach: Ready recovery.conf
> as a configuration file after postgresql.conf, but keep it as a file to
> start recovery. That doesn't break any old workflows, it gets you all
> the advantages of ha
On 01/08/2015 12:57 PM, Peter Eisentraut wrote:
>> > c) Infrastructure for changing settings effective during recovery. Right
>> >now we'd have to rebuild a lot of guc infrasturcture to allow
>> >that. It'd not be that hard to allow changing parameters like
>> >restore_command, primary_
On 1/6/15 4:40 PM, Josh Berkus wrote:
>> Btw., I'm not sure that everyone will be happy to have primary_conninfo
>> > visible, since it might contain passwords.
> Didn't we discuss this? I forgot what the conclusion was ... probably
> not to put passwords in primary_conninfo.
One can always say,
On 1/6/15 8:08 PM, Andres Freund wrote:
> On 2015-01-05 20:43:12 -0500, Peter Eisentraut wrote:
>> For example, putting recovery target parameters into postgresql.conf
>> might not make sense to some people. Once you have reached the recovery
>> end point, the information is obsolete. Keeping it
On 01/07/2015 02:31 PM, Peter Eisentraut wrote:
> On 1/6/15 7:33 PM, Josh Berkus wrote:
>> D. Wierd name: for those doing only replication, not PITR,
>> "recovery.conf" is completely baffling.
>
> I don't disagree, but "standby.enabled" or whatever isn't any better,
> for the inverse reason.
Yeah
On 1/6/15 7:33 PM, Josh Berkus wrote:
> D. Wierd name: for those doing only replication, not PITR,
> "recovery.conf" is completely baffling.
I don't disagree, but "standby.enabled" or whatever isn't any better,
for the inverse reason.
But replication and PITR are the same thing, so any name is go
Andres Freund wrote:
> On 2015-01-06 17:08:20 -0800, Josh Berkus wrote:
>> On 01/06/2015 04:42 PM, Andres Freund wrote:
>>> On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
F. Inability to remaster without restarting the replica.
>>>
>>> That has pretty much nothing to do with the topic at ha
On 01/06/2015 05:17 PM, Andres Freund wrote:
> A real solution to this requires more. You need to 1) disable writing
> any wal 2) force catchup of all possible standbys, including apply. Most
> importantly of the new master. This requires knowing which standbys
> exist. 3) promote new master. 4) on
On 2015-01-06 17:08:20 -0800, Josh Berkus wrote:
> On 01/06/2015 04:42 PM, Andres Freund wrote:
> > On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
> >> F. Inability to remaster without restarting the replica.
> >
> > That has pretty much nothing to do with the topic at hand.
>
> It has *everyth
On 2015-01-05 20:43:12 -0500, Peter Eisentraut wrote:
> For example, putting recovery target parameters into postgresql.conf
> might not make sense to some people. Once you have reached the recovery
> end point, the information is obsolete. Keeping it set could be
> considered confusing.
I don't
On 01/06/2015 04:42 PM, Andres Freund wrote:
> On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
>> F. Inability to remaster without restarting the replica.
>
> That has pretty much nothing to do with the topic at hand.
It has *everything* to do with the topic at hand. The *only* reason we
can't
On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
> F. Inability to remaster without restarting the replica.
That has pretty much nothing to do with the topic at hand.
> I. Fairly duplicative options between pg.conf and recovery.conf (i.e.
> "standby_mode" vs. "hot_standby")
Those aren't the same
Peter, all:
Let me go over the issues I find with recovery.conf, based on 3 aspects
of my experience (1) doing DBA support (2) as a tool author (HandyRep)
and (3) as a trainer, teaching new users about it. If we agree on a
list of problems with the current setup (as well as a list of benefits)
th
On 01/06/2015 01:22 PM, Peter Eisentraut wrote:
> That said, there is a much simpler way to achieve that specific
> functionality: Expose all the recovery settings as fake read-only GUC
> variables. See attached patch for an example.
I have no objections to that idea in principle. As long as it
On 1/6/15 12:57 AM, Josh Berkus wrote:
> On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
>> The wins on the other hand are obscure: You can now use SHOW to inspect
>> recovery settings. You can design your own configuration file include
>> structures to set them. These are not bad, but is that al
On 06/01/15 18:57, Josh Berkus wrote:
On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
I have previously argued for a different approach: Ready recovery.conf
as a configuration file after postgresql.conf, but keep it as a file to
start recovery. That doesn't break any old workflows, it gets yo
On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
> The wins on the other hand are obscure: You can now use SHOW to inspect
> recovery settings. You can design your own configuration file include
> structures to set them. These are not bad, but is that all?
That's not the only potential win, and i
I think this is a valuable effort, but I wonder how we are going to
arrive at a consensus. I don't see any committer supporting these
changes. Clearly, there are some advantages to having recovery
parameters be GUCs, but the proposed changes also come with some
disadvantages, and the tradeoffs are
On 24/12/14 20:11, Alex Shulgin wrote:
Alex Shulgin writes:
- the StandbyModeRequested and StandbyMode should be lowercased like
the rest of the GUCs
Yes, except that standby_mode is linked to StandbyModeRequested, not the
other one. I can try see if there's a sane way out of this.
As I s
Alex Shulgin writes:
> Petr Jelinek writes:
>>
>> I had a quick look, the patch does not apply cleanly anymore but it's
>> just release notes so nothing too bad.
>
> Yes, there were some ongoing changes that touched some parts of this and
> I must have missed the latest one (or maybe I was waiti
Petr Jelinek writes:
>
> I had a quick look, the patch does not apply cleanly anymore but it's
> just release notes so nothing too bad.
Yes, there were some ongoing changes that touched some parts of this and
I must have missed the latest one (or maybe I was waiting for it to
settle down).
> I
On 12/12/14 16:34, Alex Shulgin wrote:
Alex Shulgin writes:
Alex Shulgin writes:
Here's an attempt to revive this patch.
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
The default for the new GUC is 'pause', as in
Alex Shulgin writes:
> Alex Shulgin writes:
>>
>> Here's an attempt to revive this patch.
>
> Here's the patch rebased against current HEAD, that is including the
> recently committed action_at_recovery_target option.
>
> The default for the new GUC is 'pause', as in HEAD, and
> pause_at_recover
Andres Freund writes:
> On 2014-12-02 17:25:14 +0300, Alex Shulgin wrote:
>> I'd be in favor of a solution that works the same way as before the
>> patch, without the need for extra trigger files, etc., but that doesn't
>> seem to be nearly possible. Whatever tricks we might employ will likely
On 2014-12-02 17:25:14 +0300, Alex Shulgin wrote:
> I'd be in favor of a solution that works the same way as before the
> patch, without the need for extra trigger files, etc., but that doesn't
> seem to be nearly possible. Whatever tricks we might employ will likely
> be defeated by the fact that
On 12/02/2014 10:31 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 12/02/2014 06:25 AM, Alex Shulgin wrote:
>
>>> Whatever tricks we might employ will likely
>>> be defeated by the fact that the oldschool user will fail to *include*
>>> recovery.conf in the main conf file.
>>
>> Well, can we
Josh Berkus wrote:
> On 12/02/2014 06:25 AM, Alex Shulgin wrote:
> > Whatever tricks we might employ will likely
> > be defeated by the fact that the oldschool user will fail to *include*
> > recovery.conf in the main conf file.
>
> Well, can we merge this patch and then fight out what to do for
On 12/02/2014 06:25 AM, Alex Shulgin wrote:
>> I am not in favor of this part. It may be better to let the users know
>> > that their old configuration is not valid anymore with an error. This
>> > patch cuts in the flesh with a huge axe, let's be sure that users do
>> > not ignore the side pain ef
Michael Paquier writes:
> On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin wrote:
>> Here's the patch rebased against current HEAD, that is including the
>> recently committed action_at_recovery_target option.
> If this patch gets in, it gives a good argument to jump to 10.0 IMO.
> That's not a bad
On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin wrote:
> Here's the patch rebased against current HEAD, that is including the
> recently committed action_at_recovery_target option.
If this patch gets in, it gives a good argument to jump to 10.0 IMO.
That's not a bad thing, only the cost of making rec
Alex Shulgin writes:
>
> Here's an attempt to revive this patch.
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
The default for the new GUC is 'pause', as in HEAD, and
pause_at_recovery_target is removed completely in fav
On 11/24/2014 02:18 PM, Alex Shulgin wrote:
>
> Josh Berkus writes:
Before I go into my ideas, though, what does the current patch do
regarding non-replication PITR?
>>>
>>> It removes that $PGDATA/standby.enable trigger file it relies on to
>>> start the PITR in the first place.
>
Josh Berkus writes:
>>>
>>> Before I go into my ideas, though, what does the current patch do
>>> regarding non-replication PITR?
>>
>> It removes that $PGDATA/standby.enable trigger file it relies on to
>> start the PITR in the first place.
>
> OK, and that's required for replication too? I'm
On 11/24/2014 02:00 PM, Alex Shulgin wrote:
>
> Josh Berkus writes:
>>>
>>> only that you need to start in recovery mode to start replication
>>
>> Right, but my point is that having a trigger file *is not necessary for
>> replication, only for PITR* -- and maybe not necessary even for PITR.
>> T
On 2014-11-24 12:02:52 -0800, Josh Berkus wrote:
> On 11/24/2014 09:24 AM, Jaime Casanova wrote:
> >> ... I don't honestly think we need a 4th method for promotion.
> >>
> >
> > this is not for promotion, this is to force postgres to start in
> > recovery mode and read recovery configuration param
Josh Berkus writes:
>>
>> only that you need to start in recovery mode to start replication
>
> Right, but my point is that having a trigger file *is not necessary for
> replication, only for PITR* -- and maybe not necessary even for PITR.
> That is, in a streaming replication configuration, hav
Jaime Casanova writes:
>>>
>>> Either way, from the code it is clear that we only stay in recovery if
>>> standby_mode is directly turned on. This makes the whole check for a
>>> specially named file unnecessary, IMO: we should just check the value of
>>> standby_mode (which is off by default).
On 11/24/2014 09:24 AM, Jaime Casanova wrote:
>> ... I don't honestly think we need a 4th method for promotion.
>>
>
> this is not for promotion, this is to force postgres to start in
> recovery mode and read recovery configuration parameters.
>
>> The main reason to want a "we're in recovery fil
On Mon, Nov 24, 2014 at 12:24 PM, Jaime Casanova wrote:
> On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus wrote:
>> On 11/21/2014 09:35 AM, Alex Shulgin wrote:
>>> Hello,
>>>
>>> Here's an attempt to revive this patch.
>>
>> Yayy! Thank you.
>>
People might not like me for the suggestion, but
On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus wrote:
> On 11/21/2014 09:35 AM, Alex Shulgin wrote:
>> Hello,
>>
>> Here's an attempt to revive this patch.
>
> Yayy! Thank you.
>
>>> People might not like me for the suggestion, but I think we should
>>> simply always include a 'recovery.conf' in $
Stephen Frost wrote
> * Alvaro Herrera (
> alvherre@
> ) wrote:
>> Stephen Frost wrote:
>> > * Amit Kapila (
> amit.kapila16@
> ) wrote:
>> > > What exactly you mean by 'disable postgresql.auto.conf', do you
>> > > mean user runs Alter System to remove that entry or manually disable
>> > > som
Alex Shulgin writes:
> Maybe we should move these check/assign hooks to xlog.c, but that's
> likely going to create header files dependency problem due to use of
> GucSource in the hook prototype...
As far as that goes, there is already plenty of precedent for declaring
assorted check/assign hook
On 2014-11-24 10:13:58 -0500, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost wrote:
> > > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > > > What exactly you mean by 'disable postgresql.auto.conf', do you
> > > > mean user runs Alter System to remov
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>
> > > > Last I paid attention to this, there was a clear way to disable the
> > > > inclusion of postgresql.auto.conf in the postgresql.conf. If that's
> > > > gone,
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Last I paid attention to this, there was a clear way to disable the
> > > inclusion of postgresql.auto.conf in the postgresql.conf. If that's
> > > gone, then there is a serious problem. Administrators who manage the
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > > What exactly you mean by 'disable postgresql.auto.conf', do you
> > > mean user runs Alter System to remove that entry or manually disable
> > > some particular entry?
Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > What exactly you mean by 'disable postgresql.auto.conf', do you
> > mean user runs Alter System to remove that entry or manually disable
> > some particular entry?
>
> Last I paid attention to this, there was a clear way to
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> What exactly you mean by 'disable postgresql.auto.conf', do you
> mean user runs Alter System to remove that entry or manually disable
> some particular entry?
Last I paid attention to this, there was a clear way to disable the
inclusion of postgre
Josh Berkus writes:
>>
>> Well, the latest version of this patch fails to start when it sees
>> 'recovery.conf' in PGDATA:
>>
>> FATAL: "recovery.conf" is not supported anymore as a recovery method
>> DETAIL: Refer to appropriate documentation about migration methods
>>
>> I've missed al
Alex Shulgin writes:
>
>>> > * Why do you include xlog_internal.h in guc.c and not xlog.h?
>>
>>> we actually need both but including xlog_internal.h also includes xlog.h
>>> i added xlog.h and if someone things is enough only putting
>>> xlog_internal.h let me know
>>
>> What's required from xlo
On 2014-11-21 10:59:23 -0800, Josh Berkus wrote:
> On 11/21/2014 10:54 AM, Stephen Frost wrote:
> > * Josh Berkus (j...@agliodbs.com) wrote:
> >>> Either way, from the code it is clear that we only stay in recovery if
> >>> standby_mode is directly turned on. This makes the whole check for a
> >>>
On Sat, Nov 22, 2014 at 12:24 AM, Stephen Frost wrote:
>
> * Josh Berkus (j...@agliodbs.com) wrote:
> > > Either way, from the code it is clear that we only stay in recovery if
> > > standby_mode is directly turned on. This makes the whole check for a
> > > specially named file unnecessary, IMO:
On 11/21/2014 10:54 AM, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>>> Either way, from the code it is clear that we only stay in recovery if
>>> standby_mode is directly turned on. This makes the whole check for a
>>> specially named file unnecessary, IMO: we should just chec
* Josh Berkus (j...@agliodbs.com) wrote:
> > Either way, from the code it is clear that we only stay in recovery if
> > standby_mode is directly turned on. This makes the whole check for a
> > specially named file unnecessary, IMO: we should just check the value of
> > standby_mode (which is off b
On 11/21/2014 09:35 AM, Alex Shulgin wrote:
> Hello,
>
> Here's an attempt to revive this patch.
Yayy! Thank you.
>> People might not like me for the suggestion, but I think we should
>> simply always include a 'recovery.conf' in $PGDATA
>> unconditionally. That'd make this easier.
>> Alternati
Hello,
Here's an attempt to revive this patch.
It is rebased onto the latest master and also includes handling and
documentation of newly added recovery.conf parameters such as
primary_slot_name, recovery_min_apply_delay and
recovery_target='immediate'.
The following feedback had been addressed:
On 06/04/2014 04:35 PM, Andres Freund wrote:
Hi,
On 2014-06-04 16:32:33 -0700, Josh Berkus wrote:
Can we get this patch going again for 9.5?
A patch gets going by somebody working on it.
Well yes, but it is also great to have someone remind others that it is
of interest.
JD
Greetin
Hi,
On 2014-06-04 16:32:33 -0700, Josh Berkus wrote:
> Can we get this patch going again for 9.5?
A patch gets going by somebody working on it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
All,
Can we get this patch going again for 9.5?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This patch is in "Waiting for Author" for a couple of weeks and has
received a review at least from Andres during this commit fest. As the
situation is not much progressing, I am going to mark it as "Returned
with feedback".
If there are any problems with that please let me know.
Thanks,
--
Michae
Hi,
On 2014-01-15 02:00:51 -0500, Jaime Casanova wrote:
> On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund
> wrote:
> > Hi,
> >
> > On 2013-11-15 22:38:05 -0500, Jaime Casanova wrote:
> >> sorry, i clearly misunderstood you. attached a rebased patch with
> >> those functions removed.
> >
> > * --
On Wed, Jan 15, 2014 at 2:06 AM, Jaime Casanova wrote:
> On Wed, Jan 15, 2014 at 2:00 AM, Jaime Casanova wrote:
>> On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund
>> wrote:
>>
>>> * Maybe we should rename names like pause_at_recovery_target to
>>> recovery_pause_at_target? Since we already fo
On Wed, Jan 15, 2014 at 2:00 AM, Jaime Casanova wrote:
> On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund
> wrote:
>
>> * Maybe we should rename names like pause_at_recovery_target to
>> recovery_pause_at_target? Since we already force everyone to bother
>> changing their setup...
>
> i don't
On 2013-11-20 08:10:44 -0500, Jaime Casanova wrote:
> On Tue, Nov 19, 2013 at 3:32 PM, Andres Freund wrote:
> > On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
> >> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund
> >> wrote:
> >
> >> > * I am not sure I like "recovery.trigger" as a name. It
On 2013-11-19 22:24:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
> >> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund
> >> wrote:
> >>> * Why did you change some of the recovery gucs to lowercase names, but
> >>> left out XLogRestoreCo
On Tue, Nov 19, 2013 at 3:32 PM, Andres Freund wrote:
> On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
>> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund
>> wrote:
>
>> > * I am not sure I like "recovery.trigger" as a name. It seems to close
>> > to what I've seen people use to trigger fa
Andres Freund writes:
> On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
>> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund
>> wrote:
>>> * Why did you change some of the recovery gucs to lowercase names, but
>>> left out XLogRestoreCommand?
>> This was part of the former patch, perhaps you
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
> On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund wrote:
> > * --write-standby-enable seems to loose quite some functionality in
> > comparison to --write-recovery-conf since it doesn't seem to set
> > primary_conninfo, standby anymore.
> Ye
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund wrote:
> * --write-standby-enable seems to loose quite some functionality in
> comparison to --write-recovery-conf since it doesn't seem to set
> primary_conninfo, standby anymore.
Yes... The idea here might be to generate a new file that is then
Hi,
On 2013-11-15 22:38:05 -0500, Jaime Casanova wrote:
> sorry, i clearly misunderstood you. attached a rebased patch with
> those functions removed.
* --write-standby-enable seems to loose quite some functionality in
comparison to --write-recovery-conf since it doesn't seem to set
primary_c
On 11/15/2013 06:38 AM, Jaime Casanova wrote:
>> > Please check for compiler warnings in pg_basebackup:
>> >
>> > pg_basebackup.c:1109:1: warning: ‘escapeConnectionParameter’ defined but
>> > not used [-Wunused-function]
>> > pg_basebackup.c:1168:1: warning: ‘escape_quotes’ defined but not used
>
On Fri, Nov 15, 2013 at 11:38 PM, Jaime Casanova wrote:
> those are functions that are no longer used but Josh considered they
> could become useful before release.
> i can put them inside #ifdef _NOT_USED_ decorations or just remove
> them now and if/when we find some use for them re add them
Why
On 11/13/13, 12:17 AM, Jaime Casanova wrote:
> I have rebased Michael Paquier's patch and did a few changes:
>
> * changed standby.enabled filename to recovery.trigger
> * make archive_command a SIGHUP parameter again
> * make restore_command a SIGHUP parameter
> * rename restore_command variable
On Fri, Nov 15, 2013 at 9:28 AM, Peter Eisentraut wrote:
> On 11/13/13, 12:17 AM, Jaime Casanova wrote:
>> I have rebased Michael Paquier's patch and did a few changes:
>>
>> * changed standby.enabled filename to recovery.trigger
>> * make archive_command a SIGHUP parameter again
>> * make restore
> 9.3 has include_dir and postgresql.conf has this setted:
> """
> #include_dir = 'conf.d' # include files ending in '.conf' from
> # directory 'conf.d'
> """
>
> anything before this should be up to the packagers, no?
>
> or, do you mean something else?
Well, I was
On Mon, Oct 21, 2013 at 2:57 PM, Josh Berkus wrote:
> Jaime,
>
>>> And, as I said before, we need to do the GUC merger in the same release
>>> we introduce configuration directory (or after it).
>>>
>>
>> you mean the ALTER SYSTEM syntax? anyway, why that restriction?
>
> No, I'm referring to the
Jaime,
>> And, as I said before, we need to do the GUC merger in the same release
>> we introduce configuration directory (or after it).
>>
>
> you mean the ALTER SYSTEM syntax? anyway, why that restriction?
No, I'm referring to the proposal to have an automatically created and
included conf.d d
On Mon, Oct 21, 2013 at 11:53 AM, Josh Berkus wrote:
> On 10/18/2013 02:36 PM, Andres Freund wrote:
>>> > What will likely change first is Slony and Bucardo, who have a strong
>>> > interest in dumping triggers and queues.
>> But I don't understand what that has to do with recovery.conf and
>> bre
On 10/18/2013 02:36 PM, Andres Freund wrote:
>> > What will likely change first is Slony and Bucardo, who have a strong
>> > interest in dumping triggers and queues.
> But I don't understand what that has to do with recovery.conf and
> breakage around it.
The simple thinking is this: if we announc
On 10/18/2013 02:58 PM, Jaime Casanova wrote:
> well #3 just add a line in postgresql.conf (an include_if_exists) and
> current patch gives an error in case it finds the file (i'm suggesting
> to make it a warning instead).
> how does that makes our code more complicated?
Well, that's a couple ext
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus wrote:
> Jaime,
>
>> well, after upgrade you should do checks. and even if it happens,
>> after it happens once people will be aware of the change.
>> now, some suggestions were made to avoid the problem. 1) read the file
>> if exists last in the proce
On 2013-10-18 14:16:04 -0700, Josh Berkus wrote:
> On 10/18/2013 01:35 PM, Andres Freund wrote:
> > On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
> >> I thought changeset extraction was the only thing going into core? What
> >> else do we need?
> >
> > Well, I personally want more in core mid/
On 10/18/2013 01:35 PM, Andres Freund wrote:
> On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
>> I thought changeset extraction was the only thing going into core? What
>> else do we need?
>
> Well, I personally want more in core mid/long term, but anyway.
I've lost track of the plan, then.
H
On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
> On 10/18/2013 12:29 PM, Andres Freund wrote:
> > On 2013-10-18 09:32:15 -0700, Josh Berkus wrote:
> >> For that matter, 9.4 is a very good time (relatively speaking) to break
> >> replication tools because the new logical replication is going to ca
On 10/18/2013 12:29 PM, Andres Freund wrote:
> On 2013-10-18 09:32:15 -0700, Josh Berkus wrote:
>> For that matter, 9.4 is a very good time (relatively speaking) to break
>> replication tools because the new logical replication is going to cause
>> everyone to rev their tools anyway.
>
> We're hop
On 2013-10-18 09:32:15 -0700, Josh Berkus wrote:
> For that matter, 9.4 is a very good time (relatively speaking) to break
> replication tools because the new logical replication is going to cause
> everyone to rev their tools anyway.
We're hopefully getting changeset extraction in, but there's li
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus wrote:
>
>> exactly as it is now, if it sees the recovery trigger file, then it
>> starts ArchiveRecovery and after it finish delete the file (the only
>> difference) and increment the timeline
>
> OK, so if I'm doing a PITR recovery, I just put the re
Jaime,
>> Except that we'll want 9.4's -R to do something, probably create a file
>> called conf.d/replication.conf. Mind you, it won't need the same wonky
>> quoting stuff.
>>
>
> Currently the patch uses -R to create the recovery trigger file
Right, I'm saying that we'll want to do better tha
On Fri, Oct 18, 2013 at 1:13 PM, Jaime Casanova wrote:
>>> = Code & functionality =
>>
>>> + {"restore_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
>>> + {"archive_cleanup_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
>>> + {"recovery_end_command", PGC_POSTMASTER, WAL_ARCHIV
On Wed, Oct 16, 2013 at 1:34 PM, Josh Berkus wrote:
> Jaime,
>> = Building =
>>
>> In pg_basebackup we have now 2 unused functions:
>> escapeConnectionParameter and escape_quotes. the only use of these
>> functions was when that tool created the recovery.conf file so they
>> aren't needed anymore.
1 - 100 of 101 matches
Mail list logo
