From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Jeff Davis <pgsql(at)j-davis(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 02:03:18 |
Message-ID: | 20121211020318.GV12354@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> You know, I hadn't been taking that option terribly seriously, but
> maybe we ought to reconsider it. It would certainly be simpler, and
> as you point out, it's not really any worse from an MVCC point of view
> than anything else we do. Moreover, it would make this available to
> clients like pg_dump without further hackery.
I really don't agree with this notion that the behavior of TRUNCATE, a
top-level, seperately permissioned command, makes it OK to introduce
other busted behavior in existing commands.
> I think the current behavior, where we treat FREEZE as a hint, is just
> awful.
I agree that it's pretty grotty, but I had assumed it was at least
deterministic, ala TRUNCATE/COPY and WAL... If it isn't, then this
certainly gets really ugly really quickly.
I don't think that means we should go ahead and try to always optimize
it though- even when it isn't explicit, there will be an expectation
that it's going to work when all the 'right' conditions are met. I know
that's certainly how I feel about TRUNCATE/COPY and WAL'ing.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2012-12-11 02:48:46 | Re: Doc patch, further describe and-mask nature of the permission system |
Previous Message | Stephen Frost | 2012-12-11 01:54:04 | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |