Skip site navigation (1) Skip section navigation (2)

Re: COPY FREEZE has no warning

From: Noah Misch <noah(at)leadboat(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>,Robert Haas <robertmhaas(at)gmail(dot)com>,Andres Freund <andres(at)2ndquadrant(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY FREEZE has no warning
Date: 2013-01-30 01:34:24
Message-ID: 20130130013424.GC3524@tornado.leadboat.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)momjian(dot)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.


In response to

Responses

pgsql-hackers by date

Next:From: Noah MischDate: 2013-01-30 01:51:55
Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console
Previous:From: Morten HustveitDate: 2013-01-30 01:22:41
Subject: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group