On Sun, Sep 26, 2010 at 9:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Yeah. The original design for recovery.conf envisioned that it has only >>> a short lifespan while you're doing an archive recovery. Putting >>> parameters for slave operation into it has contorted things beyond >>> recognition. I think we really need to take two steps back and >>> reconsider the whole "parameters" versus "status" distinction there. > >> Perhaps we should consider folding recovery.conf into postgresql.conf. > > To the extent that it carries long-lived parameters, that would be > sensible. I think there's also a status component to what it's doing > though. Also, if we're trying to put SR parameters somewhere other than > postgresql.conf, it might be better if the existing parameters migrated > there instead.
Again, I think the real question is how to handle values that need to be maintained PER SLAVE from values of which there is only one copy. IMHO, whether or not it's related to HS/SR is not particularly interesting, or particularly well-defined. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
