Tom Lane wrote: > Robert Haas <robertmh...@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.3090...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
