| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
| Date: | 2012-12-11 03:30:40 |
| Message-ID: | 20121211033040.GC32120@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 10, 2012 at 08:54:04PM -0500, Stephen Frost wrote:
> I agree that it's unlikely that
> applications are depending on today's behavior of TRUNCATE making
> concurrent transactions see an empty table, but it does *not* follow
> that applications *won't* start depending on this new behavior of COPY
> FREEZE.
That is a good point. I'm not sure whether that should worry us enough to
implement an error in the scenario before letting COPY write frozen tuples.
But it's the strongest argument I've seen for imposing that prerequisite.
> Even if we could fix that, I'd be against allowing it arbitrairly for
> any regular user INSERT or UPDATE; I'm still not particularly happy with
> this approach for COPY.
Sure; COPY is the 99% important case here.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2012-12-11 04:04:00 | Re: [PATCH] pg_upgrade -o/-O regression in 9.2.2 |
| Previous Message | Karl O. Pinc | 2012-12-11 03:23:03 | Re: Multiple --table options for other commands |