From 1eb6cee499d19fc9204e059ba37fc2dac32e2f25 Mon Sep 17 00:00:00 2001 From: Simon Riggs Date: Fri, 7 Dec 2012 12:59:05 +0000 Subject: [PATCH] Clarify that COPY FREEZE is not a hard rule. Remove message when FREEZE not honoured, clarify reasons in comments and docs. --- doc/src/sgml/ref/copy.sgml | 8 +++++--- src/backend/commands/copy.c | 10 +++++----- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml index 6d34c31988..6a0fabc978 100644 --- a/doc/src/sgml/ref/copy.sgml +++ b/doc/src/sgml/ref/copy.sgml @@ -186,17 +186,19 @@ COPY { table_name [ ( FREEZE - Specifies copying the data with rows already frozen, just as they + Requests copying the data with rows already frozen, just as they would be after running the 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. + freeze rows. It is also possible in rare cases that the request + cannot be honoured for internal reasons, hence FREEZE + is more of a guideline than a hard rule. - Note that all sessions will immediately be able to see the data + 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. diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c index 09f40667f6..c4104e4d9d 100644 --- a/src/backend/commands/copy.c +++ b/src/backend/commands/copy.c @@ -1993,6 +1993,11 @@ CopyFrom(CopyState cstate) * after xact cleanup. Note that the stronger test of exactly * which subtransaction created it is crucial for correctness * of this optimisation. + * + * Note that because the test is unreliable in case of relcache reset + * we cannot guarantee that we can honour the request to FREEZE. + * If we cannot honour the request we do so silently, firstly to + * avoid noise for the user and also to avoid obscure test failures. */ if (cstate->freeze && ThereAreNoPriorRegisteredSnapshots() && @@ -2001,11 +2006,6 @@ CopyFrom(CopyState cstate) hi_options |= HEAP_INSERT_FROZEN; } - if (cstate->freeze && (hi_options & HEAP_INSERT_FROZEN) == 0) - ereport(NOTICE, - (errcode(ERRCODE_INVALID_PARAMETER_VALUE), - errmsg("FREEZE option specified but pre-conditions not met"))); - /* * We need a ResultRelInfo so we can use the regular executor's * index-entry-making machinery. (There used to be a huge amount of code -- 2.40.0