Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ... I'm still unconvinced of our ability to come
>> up with a solid design in the time we have, but I think it would make
>> sense to listen to proposals people want to make. I poked some holes
>> in Heikki's design from this morning (which was, more or less, my
>> design from last week) but that doesn't mean they can't be plugged.
>
> The only hole I saw poked was the one about how archive_mode is used to
> decide whether to start the archiver process. I think we could
> reasonably deal with that by starting the archiver iff wal_mode > 'crash'.
> There's no point in archiving otherwise, and the overhead of an idle
> archiver is small enough that we can live with the corner cases where
> you're starting an archiver you don't really need.
Agreed, but a more serious hole is what I pointed out at
http://archives.postgresql.org/message-id/4BD18722.3090608@enterprisedb.com.
That is, if you do:
wal_mode=standby
archive_command=''
max_wal_senders=5
That would be a valid configuration for enabling streaming replication
without archiving (which is possible and reasonable if you set the new
wal_keep_segments setting high enough). But as things stand, WAL
segments would be readied for archiving (.ready files would be created),
but they'e never archived and will accumulate indefinitely in the
master. You could work around that with archive_command='/usr/bin/true',
but that's not user-frienfly.
So my proposal would be:
wal_mode=crash/archive/standby
archive_mode=on/off # if on, wal_mode must be >= 'archive'
archive_command='command'
max_wal_senders=<integer> # if > 0, wal_mode must be >= 'archive'
replication_connections is not needed on the master anymore; on the
standby it enables/disables hot standby. It is ignored on the master, to
allow the same configuration file to be used on master and standby.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
