aboutsummaryrefslogtreecommitdiff
path: root/src/backend/tcop/postgres.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-11-26 15:55:43 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2012-11-26 15:55:43 -0500
commit532994299e2ff208a58376134fab75f5ae471e41 (patch)
tree640a22d6172d9dbdccf88ecc1195c6a23a3b0a8c /src/backend/tcop/postgres.c
parentd3237e04ca380d6c08f6133fde97a9d956e3161a (diff)
downloadpostgresql-532994299e2ff208a58376134fab75f5ae471e41.tar.gz
postgresql-532994299e2ff208a58376134fab75f5ae471e41.zip
Revert patch for taking fewer snapshots.
This reverts commit d573e239f03506920938bf0be56c868d9c3416da, "Take fewer snapshots". While that seemed like a good idea at the time, it caused execution to use a snapshot that had been acquired before locking any of the tables mentioned in the query. This created user-visible anomalies that were not present in any prior release of Postgres, as reported by Tomas Vondra. While this whole area could do with a redesign (since there are related cases that have anomalies anyway), it doesn't seem likely that any future patch would be reasonably back-patchable; and we don't want 9.2 to exhibit a behavior that's subtly unlike either past or future releases. Hence, revert to prior code while we rethink the problem.
Diffstat (limited to 'src/backend/tcop/postgres.c')
-rw-r--r--src/backend/tcop/postgres.c32
1 files changed, 11 insertions, 21 deletions
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 585db1af89c..1fd39f2d99b 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -976,6 +976,10 @@ exec_simple_query(const char *query_string)
plantree_list = pg_plan_queries(querytree_list, 0, NULL);
+ /* Done with the snapshot used for parsing/planning */
+ if (snapshot_set)
+ PopActiveSnapshot();
+
/* If we got a cancel signal in analysis or planning, quit */
CHECK_FOR_INTERRUPTS();
@@ -1000,19 +1004,9 @@ exec_simple_query(const char *query_string)
NULL);
/*
- * Start the portal.
- *
- * If we took a snapshot for parsing/planning, the portal may be able
- * to reuse it for the execution phase. Currently, this will only
- * happen in PORTAL_ONE_SELECT mode. But even if PortalStart doesn't
- * end up being able to do this, keeping the parse/plan snapshot
- * around until after we start the portal doesn't cost much.
+ * Start the portal. No parameters here.
*/
- PortalStart(portal, NULL, 0, snapshot_set);
-
- /* Done with the snapshot used for parsing/planning */
- if (snapshot_set)
- PopActiveSnapshot();
+ PortalStart(portal, NULL, 0, InvalidSnapshot);
/*
* Select the appropriate output format: text unless we are doing a
@@ -1735,20 +1729,16 @@ exec_bind_message(StringInfo input_message)
cplan->stmt_list,
cplan);
- /*
- * And we're ready to start portal execution.
- *
- * If we took a snapshot for parsing/planning, we'll try to reuse it for
- * query execution (currently, reuse will only occur if PORTAL_ONE_SELECT
- * mode is chosen).
- */
- PortalStart(portal, params, 0, snapshot_set);
-
/* Done with the snapshot used for parameter I/O and parsing/planning */
if (snapshot_set)
PopActiveSnapshot();
/*
+ * And we're ready to start portal execution.
+ */
+ PortalStart(portal, params, 0, InvalidSnapshot);
+
+ /*
* Apply the result format requests to the portal.
*/
PortalSetResultFormat(portal, numRFormats, rformats);