| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)mail(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: TRUNCATE SERIALIZABLE and frozen COPY |
| Date: | 2012-11-09 15:46:13 |
| Message-ID: | CA+U5nM+a96+7DZCooZZ+TUzNn=n2fGwmszH5irLde=2DBcFruQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9 November 2012 15:34, Kevin Grittner <kgrittn(at)mail(dot)com> wrote:
> If we're not talking about making conflicts with other transactions
> behave just the same as an unqualified DELETE from a user
> perspective, I'm not sure what the goal is, exactly.
Reasonable question.
My goal is to allow COPY to load frozen tuples without causing MVCC violations.
Altering TRUNCATE so it behaves perfectly from an MVCC/Serializable
perspective is a much bigger, and completely different goal, as well
as something I don't see as desirable anyway for at least 2 good
reasons, as explained. IMHO if people want MVCC/Serializable
semantics, use DELETE, possibly spending time to make unqualified
DELETE do some fancy TRUNCATE-like tricks with relfilenodes.
Forcing a tightly scoped proposal into a much wider one will just kill
this and leave it blocked.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-11-09 16:00:34 | Re: TRUNCATE SERIALIZABLE and frozen COPY |
| Previous Message | Kevin Grittner | 2012-11-09 15:40:29 | Re: TRUNCATE SERIALIZABLE and frozen COPY |