Josh Berkus <j...@agliodbs.com> wrote: > On 09/30/2014 02:39 PM, Kevin Grittner wrote: >> Josh Berkus <j...@agliodbs.com> wrote: >>> On 09/30/2014 07:15 AM, Kevin Grittner wrote: >>> >>>> At the risk of pushing people away from this POV, I'll point out >>>> that this is somewhat similar to what we do for unlogged bulk loads >>>> -- if all the conditions for doing it the fast way are present, we >>>> do it the fast way; otherwise it still works, but slower. >>> >>> Except that switching between fast/slow bulk loads affects *only* the >>> speed of loading, not the locking rules. Having a statement silently >>> take a full table lock when we were expecting it to be concurrent >>> (because, for example, the index got rebuilt and someone forgot the >>> UNIQUE) violates POLA from my perspective. >> >> I would not think that an approach which took a full table lock to >> implement the more general case would be accepted. > > Why not? There are certainly cases ... like bulk loading ... where > users would find it completely acceptable. Imagine that you're merging > 3 files into a single unlogged table before processing them into > finished data.
So the expectation is that when we implement MERGE it will, by default, take out an EXCLUSIVE lock for the entire target table for the entire duration of the command? I would have expected a bit more finesse. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
