Simon Riggs wrote:
> On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote:
>
>> * renamed wal_mode to wal_level
>
> I'm wondering whether this should be a list rather than an enum? If we
> add something in the future that adds more info to WAL but doesn't fit
> the one-dimensional model this implements then we could be in trouble.
> Should this be
>
> e.g. wal_xxxx = feature2, feature3
> e.g. wal_xxxx = feature3
> e.g. wal_xxxx = feature1
>
> recognising that some features require other features, so as an example
> feature2 requires and implies feature1.
>
> The word "level" implies a one-dimensionality that "mode" did not and I
> feel a little uncertain about that term.
That's the same concern Tom had at
http://archives.postgresql.org/message-id/17411.1272291825@sss.pgh.pa.us.
If we want to make it a list, I think it would be something like:
wal_extra_info = '' # "archive", or "archive, hot_standby"
That seems OK to me. Still, I'd like to go with "level", it's short and
descriptive of the current options, and it's not that big a deal to
rename it if we add more options in the future.
It's hard to picture what the future options might be like. Someone had
an idea years ago (you even?) to add more information like table names
or primary keys to the WAL records, to make it easier to scrape
information from the WAL for 3rd party replication solutions. Like
feeding a slony replica from the WAL. Or maybe we'd want to fold
full_page_writes to the new GUC.
If it's just one or two extra feature orthogonal to the
minimal-archive-hot_standby axis, it might still be best to keep the
wal_level name, and make it possible to tack extra options to it like a
list. Like "wal_level='archive, featureX'". "Level" would still be a
good name, that's the main dimension.
If the dependencies between the features get complicated, though, I
doubt we can correctly guess the best representation for them now anyway.
That's just my 2 cents, if others feel like "level" is painting us to
the corner, "wal_mode" with the same values is the second best option IMO.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
