On Wed, May 5, 2010 at 9:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Smith <greg@2ndquadrant.com> writes:
>> Heikki Linnakangas wrote:
>>> Let's rip out the concept of a delay altogether, and make it a boolean.
>
>> So the only user options would be "allow long-running queries to block
>> WAL application forever" and "always cancel queries on conflict?
>
> Got it in one.
>
> Obviously, this is something that would be high priority to improve in
> some fashion in 9.1. That doesn't mean that it's reasonable to drop in
> a half-baked redesign now, nor to put in the amount of work that would
> be required to have a really well-designed implementation, and most
> certainly not to uncritically ship what we've got.
If you had a genuinely better idea for how this should work, I would
be the first to endorse it, but it's becoming clear that you don't,
which makes me also skeptical of your contention that we will be
better off with no knob at all. I find that position not very
plausible. Nor do I really see how this is backing us into any kind
of a corner. If we're really concerned that we're going to suddenly
come up with a much better method of controlling this behavior (and so
far nobody seems close to having such a brilliant insight), then let's
just put a note in the documentation saying that the setting has
problems X, Y, and Z and that if we develop a better method for
controlling this behavior, the GUC may be modified or removed in a
future release. Ripping it out seems like a drastic overreaction,
particularly considering that we're already in beta.
This feature has been in the tree since December 19th when the initial
Hot Standby patch was committed, and the last significant code change
was on February 13th. It is now May 5th. The fact that you didn't
read the patch sooner is not a reason why we should rip it out now.
Yes, the current implementation is a little crufty and has some
limitations. See also work_mem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
