From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: max_standby_delay considered harmful |
Date: | 2010-05-06 01:36:24 |
Message-ID: | 3228.1273109784@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith <greg(at)2ndquadrant(dot)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. We have a ton of
other work that has to be done to get 9.0 out the door, and this feature
is something that IMO we can live without for this release.
One reason I believe this isn't so critical as all that is that it only
matters for cases where the operation on the master took an exclusive
lock. In high-performance production scenarios that's something you try
hard to avoid anyway. When you succeed, the standby behavior is moot.
Even if you can't avoid exclusive locks entirely, you may be able to
confine them to maintenance windows where performance doesn't matter
so much ... and then that goes for the standby performance as well.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-05-06 01:47:42 | Re: max_standby_delay considered harmful |
Previous Message | Greg Smith | 2010-05-06 01:17:49 | Re: max_standby_delay considered harmful |