diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2012-11-26 15:55:43 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2012-11-26 15:55:43 -0500 |
commit | 532994299e2ff208a58376134fab75f5ae471e41 (patch) | |
tree | 640a22d6172d9dbdccf88ecc1195c6a23a3b0a8c /src/backend/tcop/postgres.c | |
parent | d3237e04ca380d6c08f6133fde97a9d956e3161a (diff) | |
download | postgresql-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.c | 32 |
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); |