Re: Commits 8de72b and 5457a1 (COPY FREEZE) - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date
Msg-id 1354821046.10198.217.camel@jdavis-laptop
Whole thread Raw
In response to Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Thu, 2012-12-06 at 18:16 +0000, Simon Riggs wrote:
> > I tend to agree with Andres on this one.  This feels a bit like
> > accepting a command but then not actually following-through on it
> > if it turns out we can't actually do it.  If it's truely an optimization
> > (and I suspect my other email/question might provide insight into that),
> > then it should be something we can 'just do' without needing to be asked
> > to do it, along the same lines of not WAL'ing when the appropriate
> > conditions are met (table created in this transaction, etc, etc).
> 
> That depends whether its a command or a do-if-possible hint. Its
> documented as the latter.
> 
> Similar to the way VACUUM tries to truncate a relation, but gives up
> if it can't. And on an even closer example, VACUUM FREEZE itself,
> which doesn't guarantee that all rows are frozen at the end of it...

Also, if the set of conditions changes in the future, we would have a
problem if that caused new errors to appear.

I think a WARNING might make more sense than a NOTICE, but I don't have
a strong opinion about that.

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: How to check whether the row was modified by this transaction before?
Next
From: Stephen Frost
Date:
Subject: Re: Commits 8de72b and 5457a1 (COPY FREEZE)