Streaming Replication docs
in [PgSql]
|
Prev: pgsql: Make standby server continuously retry restoring the next WAL
Next: [HACKERS] a common place for pl/perlu modules
From: Fujii Masao on 12 Feb 2010 05:23 On Fri, Feb 12, 2010 at 7:15 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > That's actually a bit questionable, always has been even in pg_standby. > It adds a constant 1 s delay to the recovery each WAL file, which > effectively rate-limits the WAL recovery to 16MB per second. I think we > should rather add a warning to the docs, suggesting the copy-then-rename > method on Windows. Right. Adding a warning to the docs looks enough. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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: Josh Berkus on 12 Feb 2010 13:09 On 2/12/10 1:14 AM, Heikki Linnakangas wrote: > It's pretty clear that we should have a single place that documents all > the recovery.conf options. I suggest that we move the "24.3.3.1 Recovery > Settings" section after "High Availability, Load Balancing, and > Replication", and add the new streaming replication related options > there. The previous sections would still briefly describe the most > important settings and give examples, but the new section would be the > authoritative reference page for recovery.conf. I'd also suggest that we should have a cross-reference from Server Runtime Settings in Administration. --Josh Berkus -- 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: "Joshua D. Drake" on 12 Feb 2010 13:26 On Fri, 2010-02-12 at 10:22 -0800, Josh Berkus wrote: > Heikki, > > Crossing this thread over to pgsql-docs, where I think it actually belongs. > > In addition to the changes you've proposed, one thing our docs could > really use is a single reference page which we could go to for all of > the .conf files. Right now, you need to rely on postgresql.org doc > search in order to find, for example, pg_hba.conf. > > I think it would be good to put into server administration somewhere a > single page called "Configuration Files" which references: > postgresql.conf > pg_hba.conf > recovery.conf > pg_ident.conf > ... hmmm, am I missing one? Seems that should go... under "Reference" Joshua D. Drake > > --Josh Berkus > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- 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: Greg Stark on 13 Feb 2010 13:17 On Fri, Feb 12, 2010 at 9:14 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > One glaring issue with the current documentation layout is that the > documentation for the various options in recovery.conf is split in two > places. I've been trying to explain to someone how to set this all up and they keep asking me why there's a separate recovery.conf file. I thought it made sense back when it was to control PITR and was a transient file which only applied as long as it was recovering but it seems now to have become part of the normal setup of the server. It seems like it would be much easier to keep things straight if you could set up the master and all the slaves identically and they would know when they had to store or retrieve files from the WAL archive and when they had to make or listen for streaming connections based on their master/slave status -- which is the only bit which needs to be stored outside the configuration so it can be changed dynamically. The master/slave status would be indicated by a trigger file or some external master election daemon connecting and issuing a query calling a magic sql function. But having the separate recovery.conf seems kind of pointless legacy structure at this point. -- greg -- 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: Josh Berkus on 14 Feb 2010 12:35
On 2/13/10 10:17 AM, Greg Stark wrote: > But having the separate recovery.conf seems kind of pointless legacy > structure at this point. Agreed, but I've been trying to minimize my tinkering with HS/SR. Several things would need to be changed to get rid of Recovery.conf for HS and PITR. I expect that we'll get rid of Recovery.conf, and fold it into PostgreSQL.conf, in 9.1. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |