[Pgpool-general] pgpool error

Fri Sep 22 07:55:54 UTC 2006

The error indicates that there is a difference between number of rows
which each server returns. (it seems master returns more data than
secondary).

Can you send the identical query to each server to see how many rows
return?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Now I'm getting a different kind mismatch. Here's the statement log with the
> exact SQL statement that caused the mismatch. Thanks for your help.
> 
> 
> 2006-09-21 08:29:32 LOG:   pid 31074: statement: BEGIN WORK;
> 2006-09-21 08:29:32 LOG:   pid 31074: statement: SELECT
> l_time_zones.time_zone_abbr FROM users INNER JOIN l_time_zones ON
> users.time_zone=l_time_zones.id WHERE user_id=93
> 2006-09-21 08:29:32 LOG:   pid 31074: statement: LOCK customer;
> 2006-09-21 08:29:32 LOG:   pid 31074: statement: SELECT customer_id FROM
> customer WHERE call_back_date || ' ' || call_back_time AT TIME ZONE 'EDT' <=
> '2006-09-21 08:29:00' AND customer_status_id=1 AND rep_user_id is null AND
> date_created::DATE = curdate() ORDER BY call_back_date, call_back_time AT
> TIME ZONE 'EDT'
> 2006-09-21 08:29:32 ERROR: pid 31074: pool_process_query: kind does not
> match between backends master(D) secondary(C)
> 2006-09-21 08:29:32 LOG:   pid 31074: notice_backend_error: master: 1 fail
> over request from pid 31074
> 2006-09-21 08:29:32 LOG:   pid 26563: starting degeneration. shutdown master
> host 127.0.0.1(5432)
> 2006-09-21 08:29:32 LOG:   pid 26563: degeneration done. shutdown master
> host 127.0.0.1(5432)
> 
> 
> 
> -----Original Message-----
> From: Tatsuo Ishii [mailto:ishii at sraoss.co.jp] 
> Sent: Wednesday, September 20, 2006 5:44 PM
> To: rbeams at fprocessing.com
> Cc: pgpool-general at pgfoundry.org
> Subject: Re: [Pgpool-general] pgpool error
> 
> 69 = 'E' (error packet) and 84 = 'T' (row description packet).
> So it seems that master PostgreSQL returns error while secondary
> PostgreSQL returns the result of SELECT.
> 
> To investigate further, I suggest look into master PostgreSQL's log
> file to find the actual error messages. Also you might want to know
> what SQL statement causes the error.
> 
> log_statement = true
> 
> will help you.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> > Hello. I've installed pgpool 3.1.1. Can anyone help me with this error
> > message and what it means. I can't find any description anywhere. Also, my
> > master/secondary run fine with replication and load balancing for a few
> > hours running standard SQL SELECT'S, INSERT'S, and UPDATE'S. However, it
> > degenerates to the secondary when it's hit with traffic (these queries use
> > LOCK tablename to make sure data is in sync. Does this error have anything
> > to do with it? Or do I need to implement a locking function on pgpool?
> > Thanks in advance.
> > 
> > 
> > "read_kind: kind does not match between backends master(69) secondary(84)"
> > 
> > 
> > #
> > # pgpool configuration file sample
> > # $Header: /cvsroot/pgpool/pgpool/pgpool.conf.sample,v 1.5 2006/06/04
> > 10:03:30 t-ishii Exp $
> > 
> > # Host name or IP address to listen on: '*' for all, '' for no TCP/IP
> > # connections
> > listen_addresses = '192.168.0.110'
> > 
> > # Port number for pgpool
> > port = 9999
> > 
> > # Unix domain socket path.  (The Debian package defaults to
> > # /var/run/postgresql.)
> > socket_dir = '/tmp'
> > 
> > # Host name where PostgreSQL server is running on.  '' means localhost
> > # using Unix domain socket.
> > backend_host_name = '127.0.0.1'
> > 
> > # port number PostgreSQL server is running on
> > backend_port = 5432
> > 
> > # Unix domain socket path for the backend.  (The Debian package defaults
> > # to /var/run/postgresql.)
> > backend_socket_dir = '/tmp'
> > 
> > # Host name where secondary PostgreSQL server is running on.  '' means
> > # localhost using Unix domain socket.
> > secondary_backend_host_name = '192.168.0.84'
> > 
> > # Port number secondary PostgreSQL server is running on.  0 means no
> > # secondary PostgreSQL.
> > secondary_backend_port = 5432
> > 
> > # Number of pre-forked child processes
> > num_init_children = 32
> > 
> > # Number of connection pools allowed for a child process
> > max_pool = 4
> > 
> > # If idle for this many seconds, child exits.  0 means no timeout.
> > child_life_time = 300
> > 
> > # If idle for this many seconds, connection to PostgreSQL closes.
> > # 0 means no timeout.
> > connection_life_time = 0
> > 
> > # If child_max_connections connections were received, child exits.
> > # 0 means no exit.
> > child_max_connections = 0
> > 
> > # Logging directory
> > logdir = '/tmp'
> > 
> > # Replication mode
> > replication_mode = true
> > 
> > # Set this to true if you want to avoid deadlock situations when
> > # replication is enabled.  There will, however, be a noticable performance
> > # degration.  A workaround is to set this to false and insert a /*STRICT*/
> > # comment at the beginning of the SQL command.
> > replication_strict = true
> > 
> > # When replication_strict is set to false, there will be a chance for
> > # deadlocks.  Set this to nonzero (in milliseconds) to detect this
> > # situation and resolve the deadlock by aborting current session.
> > replication_timeout = 5000
> > 
> > # Load balancing mode, i.e., all SELECTs except in a transaction block
> > # are load balanced.  This is ignored if replication_mode is false.
> > load_balance_mode = true
> > 
> > # Load balance weight for master and secondary.  The actual weight is
> > # calculated by weight_master divided by weight_secondary.  For
> > # example both
> > #
> > # weight_master = 10 and weight_secondary = 5
> > # weight_master = 4 and weight_secondary = 2
> > #
> > # are regarded as the master having double the weight compared to the
> > # secondary.  Master and secondary have the same weight in the default.
> > weight_master = 0.5
> > weight_secondary = 0.5
> > 
> > # If there is a data mismatch between master and secondary, start
> > # degeneration to stop replication mode.
> > replication_stop_on_mismatch = true
> > 
> > # Semicolon separated list of queries to be issued at the end of a session
> > reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'
> > 
> > # If true print time stamp on each log line.
> > print_timestamp = true
> > 
> > # If true, operate in master/slave mode.
> > master_slave_mode = false
> > 
> > # If true, cache connection pool.
> > connection_cache = true
> > 
> > # Health check timeout.  0 means no timeout.
> > health_check_timeout = 20
> > 
> > # Health check period.  0 means no health check.
> > health_check_period = 20
> > 
> > # Health check user
> > health_check_user = 'upfront'
> > 
> > # If true, automatically lock table with INSERT statements to keep SERIAL
> > # data consistency.  An /*INSERT LOCK*/ comment has the same effect.  A
> > # /NO INSERT LOCK*/ comment disables the effect.
> > insert_lock = false
> > 
> > # If true, ignore leading white spaces of each query while pgpool judges
> > # whether the query is a SELECT so that it can be load balanced.  This
> > # is useful for certain APIs such as DBI/DBD which is known to adding an
> > # extra leading white space.
> > ignore_leading_white_space = false
> > # If true, print all statements to the log.  Like the log_statement option
> > # to PostgreSQL, this allows for observing queries without engaging in
> full
> > # debugging.
> > log_statement = false
> 