Re: TRUNCATE SERIALIZABLE and frozen COPY

On 11/09/2012 09:34 AM, Simon Riggs wrote:
> On 8 November 2012 23:20, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
>> On 11/08/2012 08:51 PM, Simon Riggs wrote:
>>> On 8 November 2012 17:07, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs <simon(at)2ndquadrant(dot)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.
MVCC does keep history of old relfilenodes.

I thought we were able to read old MVCC versions in pg_class for
this if the snapshot required data matching older pg_class record.
> 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) ?