Re: Re: Hot Standby query cancellation and Streaming Replication integration
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Greg Stark <gsstark@mit.edu>
Cc: Josh Berkus <josh@agliodbs.com>, Greg Smith <greg@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-03-02T23:39:10Z
Lists: pgsql-hackers
Attachments
- /rtmp/diff (text/x-diff) patch
Greg Stark wrote: > On Mon, Mar 1, 2010 at 5:50 PM, Josh Berkus <josh@agliodbs.com> wrote: > > I don't think that defer_cleanup_age is a long-term solution. ?But we > > need *a* solution which does not involve delaying 9.0. > > So I think the primary solution currently is to raise max_standby_age. > > However there is a concern with max_standby_age. If you set it to, > say, 300s. Then run a 300s query on the slave which causes the slave > to fall 299s behind. Now you start a new query on the slave -- it gets > a snapshot based on the point in time that the slave is currently at. > If it hits a conflict it will only have 1s to finish before the > conflict causes the query to be cancelled. > > In short in the current setup I think there is no safe value of > max_standby_age which will prevent query cancellations short of -1. If > the slave has a constant stream of queries and always has at least one > concurrent query running then it's possible that the slave will run > continuously max_standby_age-epsilon behind the master and cancel > queries left and right, regardless of how large max_standby_age is. This is sobering. I have added the attached documentation so at least this odd behavior is documented. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do