On 9 November 2012 16:27, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 9 November 2012 15:34, Kevin Grittner <kgri...@mail.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. > > If that's the goal, I question why you're insisting on touching > TRUNCATE's behavior. We already have the principle that "TRUNCATE is > like DELETE except not concurrent-safe". Why not just invent a > non-concurrent-safe option to COPY that loads prefrozen tuples into a > new heap, and call it good? There will be visibility oddness from that > definition, sure, but AFAICS there will be visibility oddness from what > you're talking about too. You'll just have expended a very great deal > of effort to make the weirdness a bit different. Even if the TRUNCATE > part of it were perfectly clean, the "load prefrozen tuples" part won't > be --- so I'm not seeing the value of changing TRUNCATE.
This is wonderful thought and I wish I'd thought of it. My digression via truncate now annoys me. Yes, there are objections and I've read what Robert has said. An explicit new option is perfectly entitled to introduce new behaviour and won't cause a problem with existing applications. I personally don't care about serializable stuff here, and nor do most others. They just want a way to load new data quickly. It is important to me that we do things in well principled ways, but the task at hand is data loading not perfect visibility guarantees. So what we're talking about here is a new mode for COPY, that when requested will pre-freeze tuples when loading into a newly created/truncated table. If the table isn't newly created/truncated then we'll just ignore it and continue. I see no need to throw an error, since that will just cause annoying usability issues. COPY FREEZE here we come, with extensive docs to explain the trade-off the user is accepting. -- 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
