The Monday 20 December 2010 10:13:01, Tatsuo Ishii wrote :
> > I will try to answer your TODO items one by one following emals...
Ok. Here is a patch with corrections corresponding to your answers, to be
applied to the file provided in the previous email.
>
> TODO : what does this refer to, there is no 3 in the array ?
> A: It referes to "row mode".
Ok, added.
>
> TODO : is that true ? It seems to me the JDBC driver starts a
> transaction only on first DDL query (in read committed mode at least).
>
> A: Really? I do not observe what you said with
> postgresql-8.4-701.jdbc4.jar.
I've just checked, and I was mistaken :)
>
> TODO: Are DDL queries accounted for in the load balancing algorithm ?
> A: Yes.
Corrected
>
> TODO: can a table be non-distributed and non-replicated, and still be
> used in parallel mode ?
> A: Not sure. will check.
Ok
>
> TODO: should we define 'pool' in this context ? I find it a bit confusing
> A: The reason why we use 'pool' is just for a historical reason...
Ok, so I've put a definition, tell me if I'm wrong
>
> TODO: Should be explained in more detail. I guess it's only for the
> 'rsync' method, not PITR…
> A: You are correct.
Modified
>
> TODO: What is the point of 'flushing the sequences' ? Don't we trust
> WAL recovery ?
> A: PostgreSQL does not log sequence value whenever it counts
> up. Instead it logs 'discretely'. So just redoing from WAL, it's
> possible that slave loses upto 32 sequences. See
> src/backend/commands/sequence.c.
I still don't get it. The purpose of this is just to avoid having a hole of 32
values in the sequence ? Or is it useful in replication mode and not in
master-slave? Because having a hole in a sequence is something that happens
all the time.
>
> TODO: contradiction in the previous sentence md5 is supported by using
> "pool_passwd".
> A: You are correct.
Yes, but is clear text password supported or not ? :)
>
> TODO: what happens then ? Is it rejected ?
> A: No. Inconsistent values will be inserted.
Ok, corrected
>
> TODO: I don't really get this one. Can somebody explain ?
> A: Me neither:-) Let me check...
>
> <p>The USING CLAUSE is converted to an ON CLAUSE by the query rewrite
> process. Therefore, when "*" is used at target list, the row of the same
> column name appears.</p> TODO: What does it mean ?
> A: I don't know neither:-) Let me check...
>
> TODO: This following section may be completely false. I tried to
> understand the general meaning of the original text, and look into
> pgpool's code to understand.
> A: Let me check...
Ok, I'll wait on these 3 ones too.
Marc Cousin
Dalibo
*** pgpool-en.html.orig 2010-12-20 10:59:22.587168763 +0100
--- pgpool-en.html 2010-12-20 11:43:10.853182334 +0100
***************
*** 221,227 ****
<tr>
<th>Function/Mode</th>
! <th>raw Mode</th>
<th>Replication Mode</th>
<th>Master/Slave Mode</th>
<th>Parallel Query Mode</th>
--- 221,227 ----
<tr>
<th>Function/Mode</th>
! <th>Raw Mode (*3)</th>
<th>Replication Mode</th>
<th>Master/Slave Mode</th>
<th>Parallel Query Mode</th>
***************
*** 303,309 ****
<li>(*3) Clients simply connect to the PostgreSQL servers
via pgpool-II. This mode is useful for simply limiting excess
connections to the servers, or enabling failover with multiple
! servers. TODO : what does this refer to, there is no 3 in the array ?
</ul>
</p>
--- 303,309 ----
<li>(*3) Clients simply connect to the PostgreSQL servers
via pgpool-II. This mode is useful for simply limiting excess
connections to the servers, or enabling failover with multiple
! servers.
</ul>
</p>
***************
*** 1281,1288 ****
Note: the JDBC driver has an autocommit option. If autocommit is false, the JDBC
driver sends "BEGIN" and "COMMIT" by himself. So pgpool cannot do any load
balancing. You need to call setAutoCommit(true) to enable autocommit.
- TODO : is that true ? It seems to me the JDBC driver starts a transaction only
- on first DDL query (in read committed mode at least).
</font>
</p>
--- 1281,1286 ----
***************
*** 1303,1310 ****
In addition to that, set
<code>master_slave_mode</code> and <code>load_balance_mode</code> to
true. pgpool-II will then send queries that need to be replicated to the
! Master DB, and other queries will be load balanced if possible.</p>
! TODO: Are DDL queries accounted for in the load balancing algorithm ?
<p>In master/slave mode, DDL and DML for temporary table can be executed on the
master node only.
--- 1301,1310 ----
In addition to that, set
<code>master_slave_mode</code> and <code>load_balance_mode</code> to
true. pgpool-II will then send queries that need to be replicated to the
! Master DB, and other queries will be load balanced if possible. Queries sent to
! Master DB because they cannot be balanced are of course accounted for in the
! load balancing algorithm.</p>
!
<p>In master/slave mode, DDL and DML for temporary table can be executed on the
master node only.
***************
*** 1998,2004 ****
<li>pool_pools, to get information on pgPool-II pools</li>
<li>pool_version, to get the pgPool_II release version</li>
</ul>
! TODO: should we define 'pool' in this context ? I find it a bit confusing
</p>
<p>the "pool_status" SQL statement was already available in previous releases,
but the other ones have appeared in release 3.0.</p>
--- 1998,2007 ----
<li>pool_pools, to get information on pgPool-II pools</li>
<li>pool_version, to get the pgPool_II release version</li>
</ul>
! <p>
! <u>Note</u> : The term 'pool' refers to the pool of PostgreSQL sessions owned by one pgpool process,
! not the whole sessions owned by pgpool.
! </p>
</p>
<p>the "pool_status" SQL statement was already available in previous releases,
but the other ones have appeared in release 3.0.</p>
***************
*** 2135,2144 ****
<font color="red">caution: Stop autovacuum on the master node (the
first node which is up and running). Autovacuum may change the contents
of the database and might cause inconsistency after online recovery if
! it's running.</font>
</p>
- TODO: Should be explained in more detail. I guess it's only for the
- 'rsync' method, not PITR…
<p>
If the target PostgreSQL server has already started, you need to shut it down.
--- 2138,2147 ----
<font color="red">caution: Stop autovacuum on the master node (the
first node which is up and running). Autovacuum may change the contents
of the database and might cause inconsistency after online recovery if
! it's running. This applies only if you're recovering with a simple copy mecanism, such
! as the rsync one explained below. This doesn't apply if you're using PostgreSQL's
! PITR mechanism.</font>
</p>
<p>
If the target PostgreSQL server has already started, you need to shut it down.
***************
*** 2687,2695 ****
INSERT INTO rel1(c1) SELECT 1
</pre>
cannot to be transformed, thus cannot be properly replicated in the current implementation.
</ul>
</p>
- TODO: what happens then ? Is it rejected ?
<p>Tables created by <code>CREATE TEMP TABLE</code> will be deleted at the end of
the session by specifying DISCARD ALL in reset_query_list if you are using
PostgreSQL 8.3 or later.
--- 2690,2698 ----
INSERT INTO rel1(c1) SELECT 1
</pre>
cannot to be transformed, thus cannot be properly replicated in the current implementation.
+ Values will still be inserted, with no transformation at all.
</ul>
</p>
<p>Tables created by <code>CREATE TEMP TABLE</code> will be deleted at the end of
the session by specifying DISCARD ALL in reset_query_list if you are using
PostgreSQL 8.3 or later.
_______________________________________________
Pgpool-hackers mailing list
[email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-hackers
