From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Date: | 2012-12-06 19:10:46 |
Message-ID: | 1354821046.10198.217.camel@jdavis-laptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2012-12-06 19:18:23 | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Previous Message | Andres Freund | 2012-12-06 19:08:50 | Re: How to check whether the row was modified by this transaction before? |