| От | Noah Misch |
|---|---|
| Тема | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
| Дата | |
| Msg-id | 20121211033040.GC32120@tornado.leadboat.com обсуждение |
| Ответ на | Re: Commits 8de72b and 5457a1 (COPY FREEZE) (Stephen Frost <sfrost@snowman.net>) |
| Список | pgsql-hackers |
On Mon, Dec 10, 2012 at 08:54:04PM -0500, Stephen Frost wrote: > I agree that it's unlikely that > applications are depending on today's behavior of TRUNCATE making > concurrent transactions see an empty table, but it does *not* follow > that applications *won't* start depending on this new behavior of COPY > FREEZE. That is a good point. I'm not sure whether that should worry us enough to implement an error in the scenario before letting COPY write frozen tuples. But it's the strongest argument I've seen for imposing that prerequisite. > Even if we could fix that, I'd be against allowing it arbitrairly for > any regular user INSERT or UPDATE; I'm still not particularly happy with > this approach for COPY. Sure; COPY is the 99% important case here.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера