| From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
|---|---|
| To: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
| Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>,"Simon Riggs" <simon(at)2ndquadrant(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:34:06 |
| Message-ID: | 20121109153406.77880@gmx.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Merlin Moncure wrote:
> Kevin Grittner <kgrittn(at)mail(dot)com> wrote:
>> Robert Haas wrote:
>> It seems to me that the goal would be to make this semantically
>> idential to the behavior users would see if an unqualified DELETE
>> were run against the table rather than a TRUNCATE.
>
> but, triggers would not fire, right?
Right. Perhaps "identical" was too strong a word. I was referring to
the aspect under consideration here -- making it "serializable" in
line with other MVCC operations.
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. Obviously we
would be keeping the guts of the implementation the same (swapping in
a new, empty heap).
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2012-11-09 15:40:29 | Re: TRUNCATE SERIALIZABLE and frozen COPY |
| Previous Message | Merlin Moncure | 2012-11-09 15:24:09 | Re: TRUNCATE SERIALIZABLE and frozen COPY |