Re: Commits 8de72b and 5457a1 (COPY FREEZE)
От | Simon Riggs |
---|---|
Тема | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Дата | |
Msg-id | CA+U5nMJqAeX0vUY+G-o2uKx+tDtyM3wzkZji7DfRz0wheFZLig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Commits 8de72b and 5457a1 (COPY FREEZE) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Commits 8de72b and 5457a1 (COPY FREEZE)
|
Список | pgsql-hackers |
On 6 December 2012 17:02, Stephen Frost <sfrost@snowman.net> wrote: > * Simon Riggs (simon@2ndQuadrant.com) wrote: >> It's not a bug. Requesting a useful, but not critical optimisation is >> just a hint. The preconditions are not easy to understand, so I see no >> reason to punish people that misunderstand, or cause programs to fail >> in ways that need detailed understanding to make them work again. > > 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... -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: