On Mon, Dec 10, 2012 at 08:32:53AM -0500, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > On Fri, Dec 07, 2012 at 06:51:18PM -0500, Stephen Frost wrote: > > > Now, what I've honestly been hoping for on this thread was for someone > > > to speak up and point out why I'm wrong about this concern and explain > > > how this patch addresses that issue. If that's been done, I've missed > > > it.. > > [...] > > So, apparently I'm not wrong about my concern, but no one seems to share > my feelings on this change. > > I continue to hold that this could end up being a slippery slope for us > to go down wrt 'correctness' vs. 'do whatever the user wants'.
I agree we should be reticent to compromise correctness for convenience. Compromising mere bug-compatibility, trading one incorrect behavior for another incorrect behavior, is not as bad. Furthermore, today's behavior in question is not something I can see applications deliberately and successfully relying upon. > If we > keep this to only COPY and where the table has to be truncated/created > in the same transaction (which requires the user to have sufficient > privileges to do non-MVCC-safe things on the table already), perhaps > it's alright. Extending it to cases not involving a just-created or just-truncated table really would compromise correctness; errors could leave the table in an otherwise-impossible state. Let's indeed not go there. I see no particular need to restrict this to COPY; that's just the most important case by far. As a side note, the calculus for whether to extend the optimization to INSERT and UPDATE differs from that for WAL avoidance. WAL avoidance can be a substantial loss when the total change is small. For pre-hinting/freezing, the worst case is having needlessly checked a few local variables to rule out the optimization. > It'll definitely reduce the interest in finding a real > solution though, which is unfortunate. That effect seems likely, but I do not find it unfortunate. The change variant I have advocated does not stand in contrast to some "real solution" to PostgreSQL's treatment for readers of tables created or truncated by a transaction not in the reader's snapshot. The two topics interact at arm's length. Bundling them into one patch, artificially making them to stand or fall as a pair, is not a win for PostgreSQL. That does raise another disadvantage of making the change syntax-controlled: if we someday implement the other improvement, COPY FREEZE will have minimal reason not to be the default. FREEZE then becomes a relic noise word. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
