| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: max_standby_delay considered harmful |
| Date: | 2010-05-05 20:52:26 |
| Message-ID: | 1273092746.4535.4776.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2010-05-05 at 16:58 +0300, Heikki Linnakangas wrote:
> Let's have a setting similar to
> statement_timeout, that specifies how long a statement is allowed to
> run until it becomes subject to killing if it conflicts with recovery
> (actually, it would have to be a per-transaction setting, at least in
> serializable mode). This would be similar to Tom's proposal, and it
> would have the same drawback that it would give no guarantee on how
> much the standby can fall behind. However, it would be easier to
> understand:
> a query gets to run for X seconds, and after that it will be killed if
> it gets in the way.
If you want this, I have no problem with you getting this (though new feature
alert sirens going off, presumably).
I only have a problem with the suggestion that this replaces the current
max_standby_delay. There is no good case for only a single option.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2010-05-05 21:45:14 | On a somewhat disappointing correspondence (was: max_standby_delay considered harmful) |
| Previous Message | Simon Riggs | 2010-05-05 20:51:12 | Re: max_standby_delay considered harmful |