On Fri, Feb 01, 2013 at 12:57:18PM -0500, Bruce Momjian wrote: > On Tue, Jan 29, 2013 at 08:34:24PM -0500, Noah Misch wrote: > > On Fri, Jan 25, 2013 at 11:28:58PM -0500, Bruce Momjian wrote: > > > BEGIN; > > > TRUNCATE vistest; > > > SAVEPOINT s1; > > > COPY vistest FROM stdin CSV FREEZE; > > > ERROR: cannot perform FREEZE because of previous table activity in the > > > current transaction > > > COMMIT; > > > > > > Clearly it was truncated in the same transaction, but the savepoint > > > somehow invalidates the freeze. There is a C comment about it: > > > > The savepoint prevents the COPY FREEZE, because COPY FREEZE needs the table > > to > > have been created or truncated in the current *sub*transaction. Issuing > > "RELEASE s1" before the COPY makes it work again, for example. > > > > > > > > * BEGIN; > > > * TRUNCATE t; > > > * SAVEPOINT save; > > > * TRUNCATE t; > > > * ROLLBACK TO save; > > > * COPY ... > > > > This is different. The table was truncated in the current subtransaction, > > and > > it's safe in principle to apply the optimization. Due to an implementation > > artifact, we'll reject it anyway. > > OK, so, should we change the error message: > > cannot perform FREEZE because of transaction activity after table > creation or truncation > > to > > cannot perform FREEZE because the table was not created or > truncated in the current subtransaction > > or do we need to keep the "transaction activity" weasel wording because > of the second case you listed above? I am suspecting the later.
Let's touch on the exception in passing by using the phrase "last truncated", giving this wording for both the second and the third COPY FREEZE error sites: cannot perform FREEZE because the table was not created or last truncated in the current subtransaction -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers