max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Heikki Linnakangas on 6 May 2010 10:39 Simon Riggs wrote: > On Thu, 2010-05-06 at 16:09 +0200, Dimitri Fontaine wrote: >> Simon Riggs <simon(a)2ndQuadrant.com> writes: >>> It would be easier to implement a conflict resolution plugin that is >>> called when a conflict occurs, allowing users to have a customisable >>> mechanism. Again, I have no objection to that proposal. >> To implement, if you say so, no doubt. To use, that means you need to >> install a contrib module after validation that the trade offs there are >> the one you're interested into, or you have to code it yourself. In C. >> >> I don't see that as an improvement over what we have now. Our main >> problem seems to be the documentation of the max_standby_delay, where we >> give the impression it's doing things the code can not do. IIUC. > > I meant "easier to implement than what Florian suggested". > > The plugin would also allow you to have the pause/resume capability. Not the same plugin. A hook for stop/resume would need to be called before and/or after each record, the one for conflict resolution would need to be called at each conflict. Designing a good interface for a plugin is hard, you need at least a couple of samples ideas for plugins that would use the hook, before you know the interface is flexible enough. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 6 May 2010 10:47 Simon Riggs wrote: > On Thu, 2010-05-06 at 16:09 +0200, Dimitri Fontaine wrote: >> Simon Riggs <simon(a)2ndQuadrant.com> writes: >>> It would be easier to implement a conflict resolution plugin that is >>> called when a conflict occurs, allowing users to have a customisable >>> mechanism. Again, I have no objection to that proposal. >> To implement, if you say so, no doubt. To use, that means you need to >> install a contrib module after validation that the trade offs there are >> the one you're interested into, or you have to code it yourself. In C. >> >> I don't see that as an improvement over what we have now. Our main >> problem seems to be the documentation of the max_standby_delay, where we >> give the impression it's doing things the code can not do. IIUC. > > I meant "easier to implement than what Florian suggested". > > The plugin would also allow you to have the pause/resume capability. Not the same plugin. A hook for stop/resume would need to be called before and/or after each record, the one for conflict resolution would need to be called at each conflict. Designing a good interface for a plugin is hard, you need at least a couple of sample ideas for plugins that would use the hook, before you know the interface is flexible enough. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 6 May 2010 10:56 On Thu, 2010-05-06 at 17:39 +0300, Heikki Linnakangas wrote: > Not the same plugin. A hook for stop/resume would need to be called > before and/or after each record, the one for conflict resolution would > need to be called at each conflict. Designing a good interface for a > plugin is hard, you need at least a couple of samples ideas for plugins > that would use the hook, before you know the interface is flexible enough. * current behaviour of max_standby_delay * pause for X time if conflict, then cancel - which is the suggested behaviour upthread * pause-if-conflict, explicit resume needed Info passed to plugin * conflict type * relfilenode * latestRemovedXid -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 6 May 2010 11:38 On Mon, May 3, 2010 at 11:37 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > I'm inclined to think that we should throw away all this logic and just > have the slave cancel competing queries if the replay process waits > more than max_standby_delay seconds to acquire a lock. This is simple, > understandable, and behaves the same whether we're reading live data or > not. Now that I've realized what the real problem is with max_standby_delay (namely, that inactivity on the master can use up the delay), I think we should do what Tom originally suggested here. It's not as good as a really working max_standby_delay, but we're not going to have that for 9.0, and it's clearly better than a boolean. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 6 May 2010 14:47
> Now that I've realized what the real problem is with max_standby_delay > (namely, that inactivity on the master can use up the delay), I think > we should do what Tom originally suggested here. It's not as good as > a really working max_standby_delay, but we're not going to have that > for 9.0, and it's clearly better than a boolean. I guess I'm not clear on how what Tom proposed is fundamentally different from max_standby_delay = -1. If there's enough concurrent queries, recovery would never catch up. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |