> Quoting "Tatsuo Ishii" <[email protected]>:
> > BTW, next release of pgpool-II will print the statement which
> > generates the error above.
> 
> Any idea when the next version will be released?

Coming January, I hope.

> Alternatively, is the current dev version stable enough for production use?

I hope so:-) Here is the current ChangeLog from dev version (not yet
committed). You might get some idea how 2.2 is like.

2008-12-31  Tatsuo Ishii  <[email protected]>
        * Add -d (debug) option to pcp commands. Patch contributed by Jun
          Kuriyama.
        
2008-12-30  Tatsuo Ishii  <[email protected]>
        * Fix bug with query cancel. It seems this has not been working since
          pgpool-II was born.
          To fix this, now we have each connection's pid and cancel key in the
          shared memory area. If a cancel packet is sent, the table is searched
          by the pid and the cancel key. If found, the actual cancel key is
          sent to each backend.

        * Fix detect_error() so that it ignores NOTICE.
          Without this following error occurs, for example:

          BEGIN;
          BEGIN;

          ERROR:  kind mismatch among backends 0[N] 1[E]

        * Enhance "kind mismatch" error message to include original query.
          This would not work for extended queries, though.

2008-12-23  Tatsuo Ishii  <[email protected]>
        * Do not make a connection cache for "postgres" database.

2008-12-20  Tatsuo Ishii  <[email protected]>
        * If SERIAL data type is used(checked in system catalog)  and
          insert_lock is true then automatically lock the table.

2008-12-13  Tatsuo Ishii  <[email protected]>
        * pool_process_query.c: refactor pool_process_query.c. Now it is
          devided into pool_process_query.c and pool_proto_modules.c.
          Also pool_proto_modules.h added which is a companion header
          file.

        * pool_process_query.c: avoid kind mismatch error caused by "SET
          TRANSACTION ISOLATION LEVEL must be called before any query".
          This could happen in following scenario:

          * M:S1:BEGIN;
          * S:S1:BEGIN;
          * M:S1:SELECT 1; <-- only sent to MASTER
          * M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
          * S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
          * M: <-- error
          * S: <-- ok since no previous SELECT is sent. kind mismatch error 
occurs!

        * pool_process_query.c: fix ReadyForQuery() by calling pool_unread
          if backend after do_error_command executed not returns read for
          query packet.

2008-12-08  Tatsuo Ishii  <[email protected]>

        * pool_process_query.c: Check serialization failure error and
          abort all nodes if so. Otherwise we allow data inconsistency
          among DB nodes. See following scenario: (M:master, S:slave)

        M:S1:BEGIN;
        M:S2:BEGIN;
        S:S1:BEGIN;
        S:S2:BEGIN;
        M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
        M:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
        S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
        S:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
        M:S1:UPDATE t1 SET i = i + 1;
        S:S1:UPDATE t1 SET i = i + 1;
        M:S2:UPDATE t1 SET i = i + 1; <-- blocked
        S:S1:COMMIT;
        M:S1:COMMIT;
        M:S2:ERROR:  could not serialize access due to concurrent update
        S:S2:UPDATE t1 SET i = i + 1; <-- success in UPDATE and data becomes 
inconsistent!

2008-12-08  Tatsuo Ishii  <[email protected]>

        * pool_process_query.c: Fix uninitialized variable in
          read_kind_from_backend. Also refactor to make it more effective
          and readable. Add lots of comments and enhance error message to
          display each kind.
        
2008-11-15  Tatsuo Ishii  <[email protected]>

        * pool_process_query.c: Fix do_error_command. If mistakely assumed
          that after sending an error query, always ReadyForQuery came
          right after that. If some debugging or logging verboseness is
          set, PostgreSQL might sends NOTICE before ReadyForQuery.

2008-11-12  Tatsuo Ishii  <[email protected]>
        
        * pool_process_query.c: Fix do_command in case of notice message
          sent right after Complete command response. See threads in
          pgpool-general:

          Subject: Re: [Pgpool-general] Pgpool-II - replication problems
          From: "nir osovsky" <[email protected]>
          Date: Wed, 12 Nov 2008 01:00:36 -0800

2008-11-07  Tatsuo Ishii  <[email protected]>

        * Fix thoughtless coding in MD5 case checking. We should have
          considered raw mode case. Bug pointed out by Duco Fijma.

2008-11-07  Tatsuo Ishii  <[email protected]>

        * Add client_idle_limit_in_recovery
        
2008-08-29  Tatsuo Ishii  <[email protected]>

        * main.c: Fix bug in fork_a_child which mistakely closed pipe fds
          which are not created yet at the startup time

        * pool_process_query.c: Allow to load balance DECLARE, FETCH and
          CLOSE. Also fix comments.

2008-08-28  Tatsuo Ishii  <[email protected]>

        * main.c: Close all file descriptors when running in daemon mode.
          Otherwise we inherit sockets from apache when it's started by
          pgpoolAdmin. This results in that port 80 is occupied for
          example.  Pach provided by Akio Ishida. Also add
          chdir("/"). This is always good for daemon programs.

        * main.c: Always fail over and restart all children. Before we do
          restart only if master has not been changed. This is wrong. If
          we have trouble with network cable or something, TCP/IP stack
          keeps on retrying for long time and the only way to prevent it
          is restarting process.

2008-08-28  Tatsuo Ishii  <[email protected]>

        * pool_process_query.c: Fix/enhance log messages and comments

--
Tatsuo Ishii
SRA OSS, Inc. Japan
_______________________________________________
Pgpool-general mailing list
[email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-general

Reply via email to