On Sat, Feb 21, 2015 at 6:45 AM, Peter Eisentraut pete...@gmx.net 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
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 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 fest app
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net 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
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net 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
On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I have written similar logic, and while it's not pleasant, it's doable.
This issue would
On 2015-01-16 21:50:16 +0900, Michael Paquier wrote:
On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-16 21:43:43 +0900, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I have written similar logic, and
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
On Mon, Jan 5, 2015 at 8:43 PM, Peter Eisentraut pete...@gmx.net 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
On 14/01/15 14:24, Robert Haas wrote:
On Mon, Jan 5, 2015 at 8:43 PM, Peter Eisentraut pete...@gmx.net 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
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_conninfo,
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, don't
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 set
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. Like I
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 going
Andres Freund and...@2ndquadrant.com 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
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 all?
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)
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 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) only
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 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 *everything* to do
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
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
On 24/12/14 20:11, Alex Shulgin wrote:
Alex Shulgin a...@commandprompt.com 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
Alex Shulgin a...@commandprompt.com writes:
Petr Jelinek p...@2ndquadrant.com 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
On 12/12/14 16:34, Alex Shulgin wrote:
Alex Shulgin a...@commandprompt.com writes:
Alex Shulgin a...@commandprompt.com 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.
Alex Shulgin a...@commandprompt.com writes:
Alex Shulgin a...@commandprompt.com 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',
Michael Paquier michael.paqu...@gmail.com writes:
On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin a...@commandprompt.com 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
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 effects, or
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 the
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 merge this
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
Andres Freund and...@2ndquadrant.com 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
Alex Shulgin a...@commandprompt.com 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
On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin a...@commandprompt.com 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
Alex Shulgin a...@commandprompt.com 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
Josh Berkus j...@agliodbs.com 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
* 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
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 disable
* 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?
Last
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 their
* 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, then there is a
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 remove that entry
Alex Shulgin a...@commandprompt.com 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
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
some particular entry?
On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus j...@agliodbs.com 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
On Mon, Nov 24, 2014 at 12:24 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus j...@agliodbs.com 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
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 file is for
Jaime Casanova ja...@2ndquadrant.com 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
Josh Berkus j...@agliodbs.com 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
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 parameters.
On 11/24/2014 02:00 PM, Alex Shulgin wrote:
Josh Berkus j...@agliodbs.com 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.
Josh Berkus j...@agliodbs.com 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:18 PM, Alex Shulgin wrote:
Josh Berkus j...@agliodbs.com 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,
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
specially
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
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.
Alternatively we
* 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 by
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 check the
On Sat, Nov 22, 2014 at 12:24 AM, Stephen Frost sfr...@snowman.net 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
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
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
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
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,
--
Michael
Hi,
On 2014-01-15 02:00:51 -0500, Jaime Casanova wrote:
On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund and...@2ndquadrant.com
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 ja...@2ndquadrant.com wrote:
On Wed, Jan 15, 2014 at 2:00 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
* Maybe we should rename names like pause_at_recovery_target
On Wed, Jan 15, 2014 at 2:00 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
* Maybe we should rename names like pause_at_recovery_target to
recovery_pause_at_target? Since we already force everyone to bother
On Tue, Nov 19, 2013 at 3:32 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
* I am not sure I like recovery.trigger as a name. It seems to close
to what
On 2013-11-19 22:24:19 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
* Why did you change some of the recovery gucs to lowercase names,
On 2013-11-20 08:10:44 -0500, Jaime Casanova wrote:
On Tue, Nov 19, 2013 at 3:32 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
* I am not sure I like
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund and...@2ndquadrant.com 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
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund and...@2ndquadrant.com 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,
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-19 22:09:48 +0900, Michael Paquier wrote:
On Tue, Nov 19, 2013 at 2:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
* Why did you change some of the recovery gucs to lowercase names, but
left out XLogRestoreCommand?
This was part
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
On Fri, Nov 15, 2013 at 9:28 AM, Peter Eisentraut pete...@gmx.net 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
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 to
On Fri, Nov 15, 2013 at 11:38 PM, Jaime Casanova ja...@2ndquadrant.com 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
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 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 announce and
On Mon, Oct 21, 2013 at 11:53 AM, Josh Berkus j...@agliodbs.com 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
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
On Mon, Oct 21, 2013 at 2:57 PM, Josh Berkus j...@agliodbs.com 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
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 just pointing
On Fri, Oct 18, 2013 at 1:13 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
= Code functionality =
+ {restore_command, PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
+ {archive_cleanup_command, PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
+ {recovery_end_command, PGC_POSTMASTER,
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 than that
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus j...@agliodbs.com 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
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
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 hopefully
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 cause
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.
Hmmm
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/long term,
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus j...@agliodbs.com 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
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 extra
On Wed, Oct 16, 2013 at 1:34 PM, Josh Berkus j...@agliodbs.com 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
Hi everyone,
Seems that the latest patch in this series is:
http://www.postgresql.org/message-id/CAB7nPqRLWLH1b0YsvqYF-zOFjrv4FRiurQ6yqcP3wjBp=tj...@mail.gmail.com
= Applying =
Reading the threads it seems there is consensus in this happening, so
let's move in that direction.
The patch applies
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.
Except that we'll want 9.4's -R to do something, probably create
99 matches
Mail list logo
