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 <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
