Re: Commits 8de72b and 5457a1 (COPY FREEZE)
От | Jeff Davis |
---|---|
Тема | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Дата | |
Msg-id | 1354821046.10198.217.camel@jdavis-laptop обсуждение исходный текст |
Ответ на | Re: Commits 8de72b and 5457a1 (COPY FREEZE) (Simon Riggs <simon@2ndQuadrant.com>) |
Список | 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 по дате отправления: