This is dump: The statement launched by PgAdmim-III appears to be trivial... ¿?
2009-01-14 17:17:19 DEBUG: pid 13364: pool_send_auth_ok: send pid 13397 to frontend 2009-01-14 17:17:19 DEBUG: pid 13364: select_load_balancing_node: selected backend id is 0 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 0 th backend Z NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 1 th backend Z NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: pool_process_query: kind from backend: Z 2009-01-14 17:17:19 DEBUG: pid 13364: pool_read_message_length: slot: 0 length: 5 2009-01-14 17:17:19 DEBUG: pid 13364: pool_read_message_length: slot: 1 length: 5 2009-01-14 17:17:19 DEBUG: pid 13364: ReadyForQuery: message length: 5 2009-01-14 17:17:19 DEBUG: pid 13364: ReadyForQuery: transaction state: I 2009-01-14 17:17:19 DEBUG: pid 13364: read kind from frontend Q(51) 2009-01-14 17:17:19 LOG: pid 13364: statement: SET DateStyle=ISO;SELECT oid, pg_encoding_to_char(encoding) AS encoding, datlastsysoid FROM pg_database WHERE oid = 612122 2009-01-14 17:17:19 DEBUG: pid 13364: waiting for backend 0 completing the query 2009-01-14 17:17:19 DEBUG: pid 13364: waiting for backend 1 completing the query 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 0 th backend S NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 1 th backend S NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: pool_process_query: kind from backend: S 2009-01-14 17:17:19 DEBUG: pid 13364: pool_read_message_length2: master slot: 0 length: 23 2009-01-14 17:17:19 DEBUG: pid 13364: pool_read_message_length2: master slot: 1 length: 23 2009-01-14 17:17:19 DEBUG: pid 13364: 0 th backend: name: DateStyle value: ISO, MDY 2009-01-14 17:17:19 DEBUG: pid 13364: 1 th backend: name: DateStyle value: ISO, MDY 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 0 th backend C NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 1 th backend C NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: pool_process_query: kind from backend: C 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 0 th backend T NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 1 th backend T NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: pool_process_query: kind from backend: T *** 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 0 th backend D NUM_BACKENDS: 2 2009-01-14 17:17:19 DEBUG: pid 13364: read_kind_from_backend: read kind from 1 th backend C NUM_BACKENDS: 2 2009-01-14 17:17:19 ERROR: pid 13364: pool_process_query: 1 th kind C does not match with master connection kind D *** 2009-01-14 17:17:19 LOG: pid 13364: notice_backend_error: 1 fail over request from pid 13364 2009-01-14 17:17:19 DEBUG: pid 13342: failover_handler called 2009-01-14 17:17:19 DEBUG: pid 13342: failover_handler: starting to select new master node 2009-01-14 17:17:19 LOG: pid 13342: starting degeneration. shutdown host 127.0.0.1(25432) 2009-01-14 17:17:19 LOG: pid 13342: failover_handler: do not restart pgpool. same master node 0 was selected 2009-01-14 17:17:19 LOG: pid 13342: failover done. shutdown host 127.0.0.1(25432) 2009-01-14 17:17:19 DEBUG: pid 13342: reap_handler called 2009-01-14 17:17:19 DEBUG: pid 13342: reap_handler: call wait3 2009-01-14 17:17:19 DEBUG: pid 13342: child 13364 exits with status 256 by signal 0 2009-01-14 17:17:19 DEBUG: pid 13398: I am 13398 2009-01-14 17:17:19 DEBUG: pid 13342: fork a new child pid 13398 2009-01-14 17:17:19 DEBUG: pid 13342: reap_handler: normally exited > -----Mensaje original----- > De: Tatsuo Ishii [mailto:[email protected]] > Enviado el: miércoles, 14 de enero de 2009 16:02 > Para: [email protected] > CC: [email protected] > Asunto: Re: [Pgpool-general] PgAdmin and pgpool-II > > Can you run pgpool with debug option (-d) and show an output > so that I could figure out what causes the problem? > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > > > Hi everybody. > > > > We are testing pgpool-II 2.1 with postgres 8.2.11 in order > to increase > > our database server capacity for an on-line store. Most of database > > load are read-only SELECTs. > > > > Our preliminary tests show that pgpool-II is working fine. > However we > > have detected a problem when using PgAdmin-III as admin/query tool. > > When we open PgAdmin-III, it shows a "mismatch" database error and > > secondary node disconnects from pgpool. > > > > This problem does not happen if we access via psql command > line, SQL > > Manager, dbvisualizer or other SQL editor. > > The problem happens when opening postgres database, so we > dropped this > > database and created it again via pgpool-II. However, > problem reamains. > > > > Is there any way to deal with this problem? Will be enough if we > > forbid our users the use of pgAdmin-II? > > > > Thanks in advance. > > > > > _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
