diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2007-09-07 20:59:26 +0000 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2007-09-07 20:59:26 +0000 |
commit | 0a51e7073c045b5fce50092dae19f398f7b38e16 (patch) | |
tree | 8f33ac25cc0653195f86b76f724b52360f3fbc80 /src/backend/commands/copy.c | |
parent | 85e79a4a83d6f6fb505474a720eb32fd88067c16 (diff) | |
download | postgresql-0a51e7073c045b5fce50092dae19f398f7b38e16.tar.gz postgresql-0a51e7073c045b5fce50092dae19f398f7b38e16.zip |
Don't take ProcArrayLock while exiting a transaction that has no XID; there is
no need for serialization against snapshot-taking because the xact doesn't
affect anyone else's snapshot anyway. Per discussion. Also, move various
info about the interlocking of transactions and snapshots out of code comments
and into a hopefully-more-cohesive discussion in access/transam/README.
Also, remove a couple of now-obsolete comments about having to force some WAL
to be written to persuade RecordTransactionCommit to do its thing.
Diffstat (limited to 'src/backend/commands/copy.c')
-rw-r--r-- | src/backend/commands/copy.c | 9 |
1 files changed, 1 insertions, 8 deletions
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c index 9bc1c388ee7..d28a6ad11c2 100644 --- a/src/backend/commands/copy.c +++ b/src/backend/commands/copy.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/commands/copy.c,v 1.285 2007/06/20 02:02:49 neilc Exp $ + * $PostgreSQL: pgsql/src/backend/commands/copy.c,v 1.286 2007/09/07 20:59:26 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1678,13 +1678,6 @@ CopyFrom(CopyState cstate) * rd_newRelfilenodeSubid can be cleared before the end of the transaction. * However this is OK since at worst we will fail to make the optimization. * - * When skipping WAL it's entirely possible that COPY itself will write no - * WAL records at all. This is of concern because RecordTransactionCommit - * might decide it doesn't need to log our eventual commit, which we - * certainly need it to do. However, we need no special action here for - * that, because if we have a new table or new relfilenode then there - * must have been a WAL-logged pg_class update earlier in the transaction. - * * Also, if the target file is new-in-transaction, we assume that checking * FSM for free space is a waste of time, even if we must use WAL because * of archiving. This could possibly be wrong, but it's unlikely. |