Re: Documentation and explanatory diagrams

On Mon, Jul 5, 2010 at 4:23 AM, Rafael Martinez
<r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> wrote:
>> For example, I'd dispute the picture of the
>> world shown on the file_based_log_shipping.png image; that's certainly
>> not the only way to set it up (the archive needn't be on the primary
>> node, right?).
>
> It is not the only way of shipping files but it is certainly the safest.
> Getting the files to ship from another source than the arch directory in
> the primary is a disaster waiting to happen if something happens to the
> process/mechanism that ships files, and this jobs is delayed or fails.

Well, if it's presented as a possible configuration rather than "the
only way to do it" then I'm fine with that. I agree many people will
set it up that way in practice.

>> The image that is called hot_standby is really showing a combination
>> of SR + log shipping.  It has nothing to do with Hot Standby.
>
> Well, what is HS without SR + log shipping. Again, this is a typical
> diagram for a DBA. What they need is an overview on how HS looks like
> with all the components we suggest they should use when using HS.

Hot Standby is the ability to run queries on the standby. That image
has nothing to do with running queries.

>> The streaming_replication image is technically not correct.  WAL
>> sender reads from disk - PostgreSQL doesn't duplicate the WAL as it's
>> generated.   It also makes it look like WAL sender/reciever are not
>> part of PostgreSQL, which of course isn't the case.
>
> Again, typical diagram for a DBA with an overview of components and how
> they interact with each other. They don't care where the wal sender gets
> the WAL information, they care that the system has two processes talking
> with each other and sending information between nodes. After testing SR,
> I can say that the secondary node generates wal files under pg_xlog when
> using SR.

I'm going to argue that diagrams should be made as technically correct
as possible even if we think that DBAs won't care.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company