Prev: [HACKERS] CIText and pattern_ops
Next: pgsql: Add missing optimizer hooks for functioncost and number of rows.
From: Robert Haas on 26 Apr 2010 06:28
On Fri, Apr 23, 2010 at 4:11 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> Well, I think the real hole is that turning archive_mode=on results in
>> WAL never being deleted unless it's successfully archived.
>
> Hm, good point.  And at least in principle you could have SR setups
> that don't care about having a backing WAL archive.
>
>> But we might be able to handle that like this:
>
>> wal_mode={standby|archive|crash}  # or whatever
>> wal_segments_always=<integer>   # keep this many segments always, for
>> SR - like current wal_keep_segments
>> wal_segments_unarchived=<integer> # keep this many unarchived
>> segments, -1 for infinite
>> max_wal_senders=<integer>          # same as now
>> archive_command=<string>            # same as now
>
>> So we always retain wal_segments_always segments, but if we have
>> trouble with archiving we'll retain up to wal_segments_archived.
>
> And when that limit is reached, what happens?  Panic shutdown?
> Silently drop unarchived data?  Neither one sounds very good.

Silently drop unarchived data. I agree that isn't very good, but
think about it this way: if archive_command is failing, then our log
shipping slave is not going to work. But letting the disk fill up on
the primary does not make it any better. It just makes the primary
stop working, too. Obviously, all of this stuff needs to be monitored
or you're playing with fire, but I don't think having a safety valve
on the primary is a stupid idea.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 26 Apr 2010 09:03
On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Tom Lane wrote:
>> Personally I agree with your objection to "crash" but not with the
>> objection to "standby".  Maybe this would be appropriate:
>>
>>       wal_mode = minimal | archive | hot_standby
>
> Ok, here's a patch implementing this proposal. It adds a new wal_mode
> setting, leaving archive_mode as it is. If you try to enable
> archive_mode when wal_mode is 'minimal', you get a warning and
> archive_mode is silently ignored. Likewise streaming replication
> connections are not allowed if wal_mode is 'minimal'.
> recovery_connections now does nothing in the master.
>
> A bit more bikeshedding before I commit this:
>
> * Should an invalid combination throw an ERROR and refuse to start,
> instead of just warning?

I think so. Otherwise silent breakage is a real possibility.

> * How about naming the parameter wal_level instead of wal_mode? That
> would better convey that the higher levels add stuff on top of the lower
> levels, instead of having different modes that are somehow mutually
> exclusive.

That works for me.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 26 Apr 2010 10:23
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
> <heikki.linnakangas(a)enterprisedb.com> wrote:
>> * How about naming the parameter wal_level instead of wal_mode? That
>> would better convey that the higher levels add stuff on top of the lower
>> levels, instead of having different modes that are somehow mutually
>> exclusive.

> That works for me.

What happens in the future if we have more options and they don't fall
into a neat superset order?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 26 Apr 2010 10:41
On Mon, Apr 26, 2010 at 10:23 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> On Mon, Apr 26, 2010 at 8:05 AM, Heikki Linnakangas
>> <heikki.linnakangas(a)enterprisedb.com> wrote:
>>> * How about naming the parameter wal_level instead of wal_mode? That
>>> would better convey that the higher levels add stuff on top of the lower
>>> levels, instead of having different modes that are somehow mutually
>>> exclusive.
>
>> That works for me.
>
> What happens in the future if we have more options and they don't fall
> into a neat superset order?

We'll decide on the appropriate solution based on whatever our needs
are at that time?

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 26 Apr 2010 15:12
On Mon, Apr 26, 2010 at 2:15 PM, Josh Berkus <josh(a)agliodbs.com> wrote:
> (a) is this checked in yet?

No.

> (b) should we delay Beta to test it?\

I suspect it's going to be checked in pretty soon, so that may not be
necessary. Not my call, though.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3 4
Prev: [HACKERS] CIText and pattern_ops
Next: pgsql: Add missing optimizer hooks for functioncost and number of rows.