On Mon, Mar 14, 2016 at 11:46 PM, Michael Paquier
wrote:
> On Mon, Mar 14, 2016 at 12:50 PM, David Steele wrote:
>> On 3/11/16 1:29 PM, David Steele wrote:
>>
>>> Unless anyone has objections I would like to mark this 'ready for
>>> committer'.
>>
>>
>> This patch is now ready for committer.
>
>
On Mon, Mar 14, 2016 at 12:50 PM, David Steele wrote:
> On 3/11/16 1:29 PM, David Steele wrote:
>
>> Unless anyone has objections I would like to mark this 'ready for
>> committer'.
>
>
> This patch is now ready for committer.
Yes, thanks, I am cool with this version as well. I guess I should
hav
On 3/11/16 1:29 PM, David Steele wrote:
Unless anyone has objections I would like to mark this 'ready for
committer'.
This patch is now ready for committer.
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On 2/8/16 2:34 PM, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> On 1/26/16 10:56 AM, Simon Riggs wrote:
>>> Removing one of "archive" or "hot standby" will just cause confusion and
>>> breakage, so neither is a good choice for removal.
>>>
>>> What we should do is
>>> 1. Map "archive" and "h
On Tue, Mar 1, 2016 at 10:02 AM, Peter Eisentraut wrote:
> On 2/8/16 7:34 AM, Michael Paquier wrote:
>> - if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
>> + if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
>> Upthread it was mentioned that switching to an approach
On 2/8/16 7:34 AM, Michael Paquier wrote:
> Shouldn't backup.sgml be updated as well? Here is the portion that I
> am referring to:
> To enable WAL archiving, set the
> configuration parameter to archive or higher,
> to on,
>
> But minimal WAL does not contain enough informa
On 2/8/16 9:36 AM, David Steele wrote:
> -#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE)
> +#define XLogIsNeeded() (wal_level >= WAL_LEVEL_REPLICA)
> <...>
> -#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_HOT_STANDBY)
> +#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_REP
Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
> > Removing one of "archive" or "hot standby" will just cause confusion and
> > breakage, so neither is a good choice for removal.
> >
> > What we should do is
> > 1. Map "archive" and "hot_standby" to one level with a new name th
On 2/7/16 4:47 PM, Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
>> Removing one of "archive" or "hot standby" will just cause confusion and
>> breakage, so neither is a good choice for removal.
>>
>> What we should do is
>> 1. Map "archive" and "hot_standby" to one level with
On Mon, Feb 8, 2016 at 6:47 AM, Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
>> Removing one of "archive" or "hot standby" will just cause confusion and
>> breakage, so neither is a good choice for removal.
>>
>> What we should do is
>> 1. Map "archive" and "hot_standby" to on
On 1/26/16 10:56 AM, Simon Riggs wrote:
> Removing one of "archive" or "hot standby" will just cause confusion and
> breakage, so neither is a good choice for removal.
>
> What we should do is
> 1. Map "archive" and "hot_standby" to one level with a new name that
> indicates that it can be used f
On Thu, Jan 28, 2016 at 10:53 AM, Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
>> What we should do is
>> 1. Map "archive" and "hot_standby" to one level with a new name that
>> indicates that it can be used for both/either backup or replication.
>> (My suggested name fo
On 1/26/16 10:56 AM, Simon Riggs wrote:
> Removing one of "archive" or "hot standby" will just cause confusion and
> breakage, so neither is a good choice for removal.
I'm pretty sure nothing would break, but I do agree that it could be
confusing.
> What we should do is
> 1. Map "archive" and "h
On 26-01-2016 12:56, Simon Riggs wrote:
> Removing one of "archive" or "hot standby" will just cause confusion and
> breakage, so neither is a good choice for removal.
>
Agree.
> What we should do is
> 1. Map "archive" and "hot_standby" to one level with a new name that
> indicates that it can b
On 1 September 2015 at 03:39, Peter Eisentraut wrote:
> - The distinction between wal_level settings "archive" and "hot_standby"
> is in the way of automation or better intelligence, because the primary
> cannot tell what the receiver intends to do with the WAL.
>
> So here is a patch to get rid
On Tue, Jan 5, 2016 at 1:04 AM, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> So we've had several rounds of discussions about simplifying replication
>> configuration in general and the wal_level setting in particular. [0][1]
>> Let's get something going.
>
> I looked at this patch, which I
On Mon, Jan 4, 2016 at 3:05 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
>> wrote:
>> > Peter Eisentraut wrote:
>> >> So we've had several rounds of discussions about simplifying replication
>> >> configuration in general and the wal_level sett
Robert Haas wrote:
> On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
> wrote:
> > Peter Eisentraut wrote:
> >> So we've had several rounds of discussions about simplifying replication
> >> configuration in general and the wal_level setting in particular. [0][1]
> >> Let's get something going.
> >
On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
wrote:
> Peter Eisentraut wrote:
>> So we've had several rounds of discussions about simplifying replication
>> configuration in general and the wal_level setting in particular. [0][1]
>> Let's get something going.
>
> I looked at this patch, which
Peter Eisentraut wrote:
> So we've had several rounds of discussions about simplifying replication
> configuration in general and the wal_level setting in particular. [0][1]
> Let's get something going.
I looked at this patch, which I think has got enough consensus that you
should just push forwa
On Mon, Nov 2, 2015 at 12:21 AM, Craig Ringer wrote:
> We need to keep both, IMO, with 'archive' as an obsolete synonym for
> hot_standby.
>
> Otherwise pg_upgrade will get grumpy, and so will users who migrate
> their configurations.
Removing options entirely arguably brings some worthwhile
simp
On 11/2/15 12:21 AM, Craig Ringer wrote:
On 1 September 2015 at 10:39, Peter Eisentraut wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
[snip]
Bike-shedding: In this patch, I removed "arc
On 2 November 2015 at 14:19, Michael Paquier wrote:
> pg_upgradecluster has some logic to switch a parameter value (see
> strrepl)
That's part of pg_wrapper, not core, though.
I'd quite like to see pg_wrapper become part of the PGDG RPMs, but
right now AFAIK it's a Debian-derived-only thing.
>
On Mon, Nov 2, 2015 at 2:21 PM, Craig Ringer wrote:
> On 1 September 2015 at 10:39, Peter Eisentraut wrote:
>> So we've had several rounds of discussions about simplifying replication
>> configuration in general and the wal_level setting in particular. [0][1]
>>
>> [snip]
>>
>> Bike-shedding: In
On 1 September 2015 at 10:39, Peter Eisentraut wrote:
> So we've had several rounds of discussions about simplifying replication
> configuration in general and the wal_level setting in particular. [0][1]
>
> [snip]
>
> Bike-shedding: In this patch, I removed "archive" and kept
> "hot_standby", be
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going. While we have not reached a complete
consensus yet, a few things have become clear:
- We would like to have fewer or easier
26 matches
Mail list logo