On 8 November 2012 23:20, Hannu Krosing <ha...@2ndquadrant.com> wrote: > On 11/08/2012 08:51 PM, Simon Riggs wrote: >> >> On 8 November 2012 17:07, Robert Haas <robertmh...@gmail.com> wrote: >>> >>> On Wed, Nov 7, 2012 at 10:34 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
