On 8 November 2012 23:20, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> On 11/08/2012 08:51 PM, Simon Riggs wrote:
>>
>> On 8 November 2012 17:07, Robert Haas <robertmhaas@gmail.com> wrote:
>>>
>>> On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs <simon@2ndquadrant.com>
>>> wrote:
>>>>
>>>> For 9.2 we discussed having COPY setting tuples as frozen. Various
>>>> details apply.
>>>> Earlier threads:
>>>> "RFC: Making TRUNCATE more "MVCC-safe"
>>>> "COPY with hints, rebirth"
>>>>
>>>> I was unhappy with changing the behaviour of TRUNCATE, and still am.
>>>> So the proposal here is to have a specific modifier on TRUNCATE
>>>> command that makes it MVCC safe by throwing a serialization error.
>>>
>>> I don't think I understand the proposal. Under what circumstances
>>> would it throw a serialization error?
>>
>> If you ask for TRUNCATE SERIALIZABLE then if someone asks for data in
>> the table and has a snapshot that can see earlier data then it will
>> throw a serializable error. So its a new kind of TRUNCATE that is MVCC
>> safe.
>
> Can't we make it so that the reader with earlier snapshot sees the data from
> the pre-truncation file ?
We could... but that would require keeping a history of relfilenodes
for an object to allow for more than one TRUNCATE event. Tracking all
of that would be hard and I don't personally think its worth that
effort.
> and we unlink the base file(s) only once nobody has a snapshot the can see
> it ?
DELETE does that if that's the semantics you want.
> or are there some subtler problems (I was under impression that we already
> did this as described above) ?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
