pg.ddx.io  pgpool-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
pgpool: Revert "Fix do_query to send sync rather than flush."
6+ messages / 1 participants
[nested] [flat]

* pgpool: Revert "Fix do_query to send sync rather than flush."
@ 2026-09-06 22:56 Tatsuo Ishii <ishii@postgresql.org>
  0 siblings, 0 replies; 6+ messages in thread

From: Tatsuo Ishii @ 2026-09-06 22:56 UTC (permalink / raw)
  To: pgpool-committers@lists.postgresql.org

Revert "Fix do_query to send sync rather than flush."

This reverts commit 1e6eb4e5bb3a2208a88dac8df0ad437fd17f819d.

This breaks implicit transaction behavior created by a pipeline.
-----------------------------------------------------------------
$ psql -p 11000 -a -f failure.sql test
DROP TABLE test;
DROP TABLE
-- start a pipeline
\startpipeline
-- CREATE a table
CREATE TABLE test(i int);
-- SELECT non-existent table, which raises an error,
-- and aborts the implicit transaction started by the pipeline.
SELECT * from a;
-- Recover from the error and closes the implicit transaction.
\syncpipeline
\endpipeline
CREATE TABLE
psql:failure.sql:11: ERROR:  relation "a" does not exist
LINE 1: SELECT * from a;
                      ^
-- Try to SELECT the table created in the previous pipeline.
-- This should fail because the creation of the table "test" was rollbacked.
SELECT * from test;
 i
---
(0 rows)
-----------------------------------------------------------------

In this example, a table named "test" is created in a pipeline.  Then
a SELECT is executed. Because the SELECT tries to retrieve rows from
non-existent table "a", it causes an error and a roll back of the
implicit transaction started by the pipeline. As a result, the table
"test" created in the pipeline does not exist at the end of the
pipeline. However, a "sync" message was issued by do_query() while
obtaining information regarding table "a".  As the sync message caused
commit of the implicit transaction started by the pipeline, creation
of "test" was not roll backed by the subsequent erroneous SELECT.

IMO this is a serious data consistency issue because it breaks the
transaction semantics. If I directly connects to PostgreSQL or pgpool
by the previous commit, and run the script, it ends up with:

SELECT * from test;
psql:failure.sql:14: ERROR:  relation "test" does not exist
LINE 1: SELECT * from test;
                      ^
which is the expected behavior.

Discussion: https://www.postgresql.org/message-id/20260907.062521.1780975513572548706.ishii@postgresql.org
Backpatch-through: v4.3

Branch
------
V4_3_STABLE

Details
-------
https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=bcc925f50579959c1830f42d80700d734df4d...

Modified Files
--------------
src/protocol/pool_process_query.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgpool: Revert "Fix do_query to send sync rather than flush."
@ 2026-09-06 22:56 Tatsuo Ishii <ishii@postgresql.org>
  0 siblings, 0 replies; 6+ messages in thread

From: Tatsuo Ishii @ 2026-09-06 22:56 UTC (permalink / raw)
  To: pgpool-committers@lists.postgresql.org

Revert "Fix do_query to send sync rather than flush."

This reverts commit c1eb10dc1df76483b3b793e012d4c40447267e0a.

This breaks implicit transaction behavior created by a pipeline.
-----------------------------------------------------------------
$ psql -p 11000 -a -f failure.sql test
DROP TABLE test;
DROP TABLE
-- start a pipeline
\startpipeline
-- CREATE a table
CREATE TABLE test(i int);
-- SELECT non-existent table, which raises an error,
-- and aborts the implicit transaction started by the pipeline.
SELECT * from a;
-- Recover from the error and closes the implicit transaction.
\syncpipeline
\endpipeline
CREATE TABLE
psql:failure.sql:11: ERROR:  relation "a" does not exist
LINE 1: SELECT * from a;
                      ^
-- Try to SELECT the table created in the previous pipeline.
-- This should fail because the creation of the table "test" was rollbacked.
SELECT * from test;
 i
---
(0 rows)
-----------------------------------------------------------------

In this example, a table named "test" is created in a pipeline.  Then
a SELECT is executed. Because the SELECT tries to retrieve rows from
non-existent table "a", it causes an error and a roll back of the
implicit transaction started by the pipeline. As a result, the table
"test" created in the pipeline does not exist at the end of the
pipeline. However, a "sync" message was issued by do_query() while
obtaining information regarding table "a".  As the sync message caused
commit of the implicit transaction started by the pipeline, creation
of "test" was not roll backed by the subsequent erroneous SELECT.

IMO this is a serious data consistency issue because it breaks the
transaction semantics. If I directly connects to PostgreSQL or pgpool
by the previous commit, and run the script, it ends up with:

SELECT * from test;
psql:failure.sql:14: ERROR:  relation "test" does not exist
LINE 1: SELECT * from test;
                      ^
which is the expected behavior.

Discussion: https://www.postgresql.org/message-id/20260907.062521.1780975513572548706.ishii@postgresql.org
Backpatch-through: v4.3

Branch
------
V4_4_STABLE

Details
-------
https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=44e454142d4784033d70c91c59a386c4e66b2...

Modified Files
--------------
src/protocol/pool_process_query.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgpool: Revert "Fix do_query to send sync rather than flush."
@ 2026-09-06 22:56 Tatsuo Ishii <ishii@postgresql.org>
  0 siblings, 0 replies; 6+ messages in thread

From: Tatsuo Ishii @ 2026-09-06 22:56 UTC (permalink / raw)
  To: pgpool-committers@lists.postgresql.org

Revert "Fix do_query to send sync rather than flush."

This reverts commit a6ac3ea54cc6c7d4b251f843154589a5d6dce31c.

This breaks implicit transaction behavior created by a pipeline.
-----------------------------------------------------------------
$ psql -p 11000 -a -f failure.sql test
DROP TABLE test;
DROP TABLE
-- start a pipeline
\startpipeline
-- CREATE a table
CREATE TABLE test(i int);
-- SELECT non-existent table, which raises an error,
-- and aborts the implicit transaction started by the pipeline.
SELECT * from a;
-- Recover from the error and closes the implicit transaction.
\syncpipeline
\endpipeline
CREATE TABLE
psql:failure.sql:11: ERROR:  relation "a" does not exist
LINE 1: SELECT * from a;
                      ^
-- Try to SELECT the table created in the previous pipeline.
-- This should fail because the creation of the table "test" was rollbacked.
SELECT * from test;
 i
---
(0 rows)
-----------------------------------------------------------------

In this example, a table named "test" is created in a pipeline.  Then
a SELECT is executed. Because the SELECT tries to retrieve rows from
non-existent table "a", it causes an error and a roll back of the
implicit transaction started by the pipeline. As a result, the table
"test" created in the pipeline does not exist at the end of the
pipeline. However, a "sync" message was issued by do_query() while
obtaining information regarding table "a".  As the sync message caused
commit of the implicit transaction started by the pipeline, creation
of "test" was not roll backed by the subsequent erroneous SELECT.

IMO this is a serious data consistency issue because it breaks the
transaction semantics. If I directly connects to PostgreSQL or pgpool
by the previous commit, and run the script, it ends up with:

SELECT * from test;
psql:failure.sql:14: ERROR:  relation "test" does not exist
LINE 1: SELECT * from test;
                      ^
which is the expected behavior.

Discussion: https://www.postgresql.org/message-id/20260907.062521.1780975513572548706.ishii@postgresql.org
Backpatch-through: v4.3

Branch
------
V4_5_STABLE

Details
-------
https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=987d806e6cd98a88a29489e6e10c2ebb93394...

Modified Files
--------------
src/protocol/pool_process_query.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgpool: Revert "Fix do_query to send sync rather than flush."
@ 2026-09-06 22:56 Tatsuo Ishii <ishii@postgresql.org>
  0 siblings, 0 replies; 6+ messages in thread

From: Tatsuo Ishii @ 2026-09-06 22:56 UTC (permalink / raw)
  To: pgpool-committers@lists.postgresql.org

Revert "Fix do_query to send sync rather than flush."

This reverts commit 22965306db058fb5d786d0dfcfe45e8b2f4f2398.

This breaks implicit transaction behavior created by a pipeline.
-----------------------------------------------------------------
$ psql -p 11000 -a -f failure.sql test
DROP TABLE test;
DROP TABLE
-- start a pipeline
\startpipeline
-- CREATE a table
CREATE TABLE test(i int);
-- SELECT non-existent table, which raises an error,
-- and aborts the implicit transaction started by the pipeline.
SELECT * from a;
-- Recover from the error and closes the implicit transaction.
\syncpipeline
\endpipeline
CREATE TABLE
psql:failure.sql:11: ERROR:  relation "a" does not exist
LINE 1: SELECT * from a;
                      ^
-- Try to SELECT the table created in the previous pipeline.
-- This should fail because the creation of the table "test" was rollbacked.
SELECT * from test;
 i
---
(0 rows)
-----------------------------------------------------------------

In this example, a table named "test" is created in a pipeline.  Then
a SELECT is executed. Because the SELECT tries to retrieve rows from
non-existent table "a", it causes an error and a roll back of the
implicit transaction started by the pipeline. As a result, the table
"test" created in the pipeline does not exist at the end of the
pipeline. However, a "sync" message was issued by do_query() while
obtaining information regarding table "a".  As the sync message caused
commit of the implicit transaction started by the pipeline, creation
of "test" was not roll backed by the subsequent erroneous SELECT.

IMO this is a serious data consistency issue because it breaks the
transaction semantics. If I directly connects to PostgreSQL or pgpool
by the previous commit, and run the script, it ends up with:

SELECT * from test;
psql:failure.sql:14: ERROR:  relation "test" does not exist
LINE 1: SELECT * from test;
                      ^
which is the expected behavior.

Discussion: https://www.postgresql.org/message-id/20260907.062521.1780975513572548706.ishii@postgresql.org
Backpatch-through: v4.3

Branch
------
V4_6_STABLE

Details
-------
https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=961ce127fec8626ef02026cb3841ff958e57c...

Modified Files
--------------
src/protocol/pool_process_query.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgpool: Revert "Fix do_query to send sync rather than flush."
@ 2026-09-06 22:56 Tatsuo Ishii <ishii@postgresql.org>
  0 siblings, 0 replies; 6+ messages in thread

From: Tatsuo Ishii @ 2026-09-06 22:56 UTC (permalink / raw)
  To: pgpool-committers@lists.postgresql.org

Revert "Fix do_query to send sync rather than flush."

This reverts commit bc3689a2d62f2083699b86feb267e90296913c26.

This breaks implicit transaction behavior created by a pipeline.
-----------------------------------------------------------------
$ psql -p 11000 -a -f failure.sql test
DROP TABLE test;
DROP TABLE
-- start a pipeline
\startpipeline
-- CREATE a table
CREATE TABLE test(i int);
-- SELECT non-existent table, which raises an error,
-- and aborts the implicit transaction started by the pipeline.
SELECT * from a;
-- Recover from the error and closes the implicit transaction.
\syncpipeline
\endpipeline
CREATE TABLE
psql:failure.sql:11: ERROR:  relation "a" does not exist
LINE 1: SELECT * from a;
                      ^
-- Try to SELECT the table created in the previous pipeline.
-- This should fail because the creation of the table "test" was rollbacked.
SELECT * from test;
 i
---
(0 rows)
-----------------------------------------------------------------

In this example, a table named "test" is created in a pipeline.  Then
a SELECT is executed. Because the SELECT tries to retrieve rows from
non-existent table "a", it causes an error and a roll back of the
implicit transaction started by the pipeline. As a result, the table
"test" created in the pipeline does not exist at the end of the
pipeline. However, a "sync" message was issued by do_query() while
obtaining information regarding table "a".  As the sync message caused
commit of the implicit transaction started by the pipeline, creation
of "test" was not roll backed by the subsequent erroneous SELECT.

IMO this is a serious data consistency issue because it breaks the
transaction semantics. If I directly connects to PostgreSQL or pgpool
by the previous commit, and run the script, it ends up with:

SELECT * from test;
psql:failure.sql:14: ERROR:  relation "test" does not exist
LINE 1: SELECT * from test;
                      ^
which is the expected behavior.

Discussion: https://www.postgresql.org/message-id/20260907.062521.1780975513572548706.ishii@postgresql.org
Backpatch-through: v4.3

Branch
------
V4_7_STABLE

Details
-------
https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=9bf2066fddc1de33fd095cc5060ed31251d4c...

Modified Files
--------------
src/protocol/pool_process_query.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* pgpool: Revert "Fix do_query to send sync rather than flush."
@ 2026-09-06 22:56 Tatsuo Ishii <ishii@postgresql.org>
  0 siblings, 0 replies; 6+ messages in thread

From: Tatsuo Ishii @ 2026-09-06 22:56 UTC (permalink / raw)
  To: pgpool-committers@lists.postgresql.org

Revert "Fix do_query to send sync rather than flush."

This reverts commit e4a3a0c13e4b5e1a015aca3db238b21b88e73e2f.

This breaks implicit transaction behavior created by a pipeline.
-----------------------------------------------------------------
$ psql -p 11000 -a -f failure.sql test
DROP TABLE test;
DROP TABLE
-- start a pipeline
\startpipeline
-- CREATE a table
CREATE TABLE test(i int);
-- SELECT non-existent table, which raises an error,
-- and aborts the implicit transaction started by the pipeline.
SELECT * from a;
-- Recover from the error and closes the implicit transaction.
\syncpipeline
\endpipeline
CREATE TABLE
psql:failure.sql:11: ERROR:  relation "a" does not exist
LINE 1: SELECT * from a;
                      ^
-- Try to SELECT the table created in the previous pipeline.
-- This should fail because the creation of the table "test" was rollbacked.
SELECT * from test;
 i
---
(0 rows)
-----------------------------------------------------------------

In this example, a table named "test" is created in a pipeline.  Then
a SELECT is executed. Because the SELECT tries to retrieve rows from
non-existent table "a", it causes an error and a roll back of the
implicit transaction started by the pipeline. As a result, the table
"test" created in the pipeline does not exist at the end of the
pipeline. However, a "sync" message was issued by do_query() while
obtaining information regarding table "a".  As the sync message caused
commit of the implicit transaction started by the pipeline, creation
of "test" was not roll backed by the subsequent erroneous SELECT.

IMO this is a serious data consistency issue because it breaks the
transaction semantics. If I directly connects to PostgreSQL or pgpool
by the previous commit, and run the script, it ends up with:

SELECT * from test;
psql:failure.sql:14: ERROR:  relation "test" does not exist
LINE 1: SELECT * from test;
                      ^
which is the expected behavior.

Discussion: https://www.postgresql.org/message-id/20260907.062521.1780975513572548706.ishii@postgresql.org
Backpatch-through: v4.3

Branch
------
master

Details
-------
https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=6f66cdbf0cc043bdd0f9fe7484fb1de8a99bb...

Modified Files
--------------
src/protocol/pool_process_query.c                  | 26 +++++++++++++---------
.../tests/039.log_backend_messages/expected.s      |  1 +
2 files changed, 17 insertions(+), 10 deletions(-)



^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2026-09-06 22:56 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-06 22:56 pgpool: Revert "Fix do_query to send sync rather than flush." Tatsuo Ishii <ishii@postgresql.org>
2026-09-06 22:56 pgpool: Revert "Fix do_query to send sync rather than flush." Tatsuo Ishii <ishii@postgresql.org>
2026-09-06 22:56 pgpool: Revert "Fix do_query to send sync rather than flush." Tatsuo Ishii <ishii@postgresql.org>
2026-09-06 22:56 pgpool: Revert "Fix do_query to send sync rather than flush." Tatsuo Ishii <ishii@postgresql.org>
2026-09-06 22:56 pgpool: Revert "Fix do_query to send sync rather than flush." Tatsuo Ishii <ishii@postgresql.org>
2026-09-06 22:56 pgpool: Revert "Fix do_query to send sync rather than flush." Tatsuo Ishii <ishii@postgresql.org>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox