On Wed, Jan 23, 2013 at 02:02:46PM -0500, Bruce Momjian wrote: > As a reminder, COPY FREEZE still does not issue any warning/notice if > the freezing does not happen: > > Requests copying the data with rows already frozen, just as they > would be after running the <command>VACUUM FREEZE</> command. > This is intended as a performance option for initial data loading. > Rows will be frozen only if the table being loaded has been created > in the current subtransaction, there are no cursors open and there > are no older snapshots held by this transaction. If those conditions > are not met the command will continue without error though will not > freeze rows. It is also possible in rare cases that the request > cannot be honoured for internal reasons, hence <literal>FREEZE</literal> > is more of a guideline than a hard rule. > > Note that all other sessions will immediately be able to see the data > once it has been successfully loaded. This violates the normal rules > of MVCC visibility and by specifying this option the user acknowledges > explicitly that this is understood. > > Didn't we want to issue the user some kind of feedback?
As no one wanted to write this patch, I have developed the attached version. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c new file mode 100644 index 8778e8b..c8c9821 *** a/src/backend/commands/copy.c --- b/src/backend/commands/copy.c *************** CopyFrom(CopyState cstate) *** 2011,2023 **** * where we can apply the optimization, so in those rare cases * where we cannot honour the request we do so silently. */ ! if (cstate->freeze && ! ThereAreNoPriorRegisteredSnapshots() && ! ThereAreNoReadyPortals() && ! (cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId() || ! cstate->rel->rd_createSubid == GetCurrentSubTransactionId())) ! hi_options |= HEAP_INSERT_FROZEN; } /* * We need a ResultRelInfo so we can use the regular executor's --- 2011,2029 ---- * where we can apply the optimization, so in those rare cases * where we cannot honour the request we do so silently. */ ! if (cstate->freeze) ! { ! if (ThereAreNoPriorRegisteredSnapshots() && ! ThereAreNoReadyPortals() && ! (cstate->rel->rd_newRelfilenodeSubid == GetCurrentSubTransactionId() || ! cstate->rel->rd_createSubid == GetCurrentSubTransactionId())) ! hi_options |= HEAP_INSERT_FROZEN; ! else ! ereport(NOTICE, (errmsg("unable to honor \"freeze\" option"))); ! } } + else if (cstate->freeze) + ereport(NOTICE, (errmsg("unable to honor \"freeze\" option"))); /* * We need a ResultRelInfo so we can use the regular executor's diff --git a/src/test/regress/expected/copy2.out b/src/test/regress/expected/copy2.out new file mode 100644 index 78c601f..126b3c7 *** a/src/test/regress/expected/copy2.out --- b/src/test/regress/expected/copy2.out *************** SELECT * FROM vistest; *** 334,345 **** --- 334,347 ---- COMMIT; TRUNCATE vistest; COPY vistest FROM stdin CSV FREEZE; + NOTICE: unable to honor "freeze" option BEGIN; INSERT INTO vistest VALUES ('z'); SAVEPOINT s1; TRUNCATE vistest; ROLLBACK TO SAVEPOINT s1; COPY vistest FROM stdin CSV FREEZE; + NOTICE: unable to honor "freeze" option SELECT * FROM vistest; a ----
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers