Re: TRUNCATE SERIALIZABLE and frozen COPY
От | Robert Haas |
---|---|
Тема | Re: TRUNCATE SERIALIZABLE and frozen COPY |
Дата | |
Msg-id | CA+TgmobgFLC+506vEyJH4WwFYHL6QcCv_XbX01nU=TrcOi4Thg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TRUNCATE SERIALIZABLE and frozen COPY (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: TRUNCATE SERIALIZABLE and frozen COPY
|
Список | pgsql-hackers |
On Fri, Nov 9, 2012 at 3:31 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > So what we're talking about here is a new mode for COPY, that when > requested will pre-freeze tuples when loading into a newly > created/truncated table. If the table isn't newly created/truncated > then we'll just ignore it and continue. I see no need to throw an > error, since that will just cause annoying usability issues. Actually, why not just have it work always? If people want to load frozen tuples into a table that's not newly created/truncated, why not let them? Sure, there could be MVCC violations, but as long as the behavior is opt-in, who cares? I think it'd be useful to a lot of people. If we want to reduce (not eliminate) the potential MVCC issues, which I think would be a good idea, we could take AccessExclusiveLock on the table when COPY (FREEZE) is used. Someone using an old snapshot but accessing the table for the first time after AEL is released could still see MVCC anomalies, but at least it would rule out things changing in mid-query, which is the case that I think would be most problematic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: