Re: COPY FREEZE has no warning - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: COPY FREEZE has no warning
Date
Msg-id 20130201175718.GC2371@momjian.us
Whole thread Raw
In response to Re: COPY FREEZE has no warning  (Noah Misch <noah@leadboat.com>)
Responses Re: COPY FREEZE has no warning  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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:
> > On Fri, Jan 25, 2013 at 11:08:56PM -0500, Tom Lane wrote:
> > > Bruce Momjian <bruce@momjian.us> writes:
> > > > !                 ereport(ERROR,
> > > > !                         (ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE,
> > > > !                         errmsg("cannot perform FREEZE because of previous table activity in the current
transaction")));
> > > 
> > > [ itch... ]  What is "table activity"?  I always thought of tables as
> > > being rather passive objects.  And anyway, isn't this backwards?  What
> > > we're complaining of is *lack* of activity.  I don't see why this isn't
> > > using the same message as the other code path, namely
> > 
> > Well, here is an example of this message:
> > 
> >     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 tablecreation or truncation

to
cannot perform FREEZE because the table was not created ortruncated 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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Turning auto-analyze off (was Re: [GENERAL] Unusually high IO for autovacuum worker)
Next
From: "Marko Tiikkaja"
Date:
Subject: Re: PL/PgSQL STRICT