Thread: pgsql: Introduce timeout handling framework
Introduce timeout handling framework Management of timeouts was getting a little cumbersome; what we originally had was more than enough back when we were only concerned about deadlocks and query cancel; however, when we added timeouts for standby processes, the code got considerably messier. Since there are plans to add more complex timeouts, this seems a good time to introduce a central timeout handling module. External modules register their timeout handlers during process initialization, and later enable and disable them as they see fit using a simple API; timeout.c is in charge of keeping track of which timeouts are in effect at any time, installing a common SIGALRM signal handler, and calling setitimer() as appropriate to ensure timely firing of external handlers. timeout.c additionally supports pluggable modules to add their own timeouts, though this capability isn't exercised anywhere yet. Additionally, as of this commit, walsender processes are aware of timeouts; we had a preexisting bug there that made those ignore SIGALRM, thus being subject to unhandled deadlocks, particularly during the authentication phase. This has already been fixed in back branches in commit 0bf8eb2a, which see for more details. Main author: Zoltán Böszörményi Some review and cleanup by Álvaro Herrera Extensive reworking by Tom Lane Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/f34c68f09671c4566854c7e20e9253d4f335c0b0 Modified Files -------------- src/backend/postmaster/autovacuum.c | 9 +- src/backend/postmaster/postmaster.c | 36 ++- src/backend/postmaster/startup.c | 22 +- src/backend/replication/walsender.c | 3 +- src/backend/storage/ipc/standby.c | 80 ++++-- src/backend/storage/lmgr/proc.c | 435 +------------------------------- src/backend/tcop/postgres.c | 15 +- src/backend/utils/init/postinit.c | 33 ++- src/backend/utils/misc/Makefile | 4 +- src/backend/utils/misc/timeout.c | 479 +++++++++++++++++++++++++++++++++++ src/include/storage/proc.h | 13 +- src/include/storage/standby.h | 3 +- src/include/utils/timeout.h | 54 ++++ 13 files changed, 688 insertions(+), 498 deletions(-)
On 07/17/2012 12:03 AM, Alvaro Herrera wrote: > Introduce timeout handling framework > > This seems to have broken Windows builds. (And if people need reminding, cross-compiling is pretty easy: <http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html> ) cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 07/17/2012 12:03 AM, Alvaro Herrera wrote:
>> Introduce timeout handling framework
> This seems to have broken Windows builds.
Yeah, my fault I think. I took out proc.h from postmaster.h, thinking
it wasn't needed anymore, but the EXEC_BACKEND code needs it.
regards, tom lane
On 17 July 2012 14:43, Andrew Dunstan <andrew@dunslane.net> wrote: > This seems to have broken Windows builds. (And if people need reminding, > cross-compiling is pretty easy: > <http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html> > ) Perhaps I'm asking a naive question, but wouldn't it be easier if people had the opportunity to use the buildfarm without actually committing something? For example, perhaps the buildfarm could be made to run on a staging branch. Commits would actually be made to the staging branch. If and when the regression tests pass, the infrastructure then pushes the staging branch commit onto the master branch, and the commit is really committed - the -commiters list is now informed of this. If there is a problem with the buildfarm, the committer receives an e-mail informing them of this. The commit is non-destructively reverted on the staging branch. I don't know that it's worth worrying about, nor if the turnaround on having a commit not break the buildfarm would be generally acceptable in this situation. It would be nice to keep commit history cleaner, though. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Excerpts from Tom Lane's message of mar jul 17 10:07:53 -0400 2012: > Andrew Dunstan <andrew@dunslane.net> writes: > > On 07/17/2012 12:03 AM, Alvaro Herrera wrote: > >> Introduce timeout handling framework > > > This seems to have broken Windows builds. > > Yeah, my fault I think. I took out proc.h from postmaster.h, thinking > it wasn't needed anymore, but the EXEC_BACKEND code needs it. Will fix. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of mar jul 17 10:07:53 -0400 2012:
>> Yeah, my fault I think. I took out proc.h from postmaster.h, thinking
>> it wasn't needed anymore, but the EXEC_BACKEND code needs it.
> Will fix.
Oh, I did it already.
regards, tom lane
On 07/17/2012 11:08 AM, Peter Geoghegan wrote: > On 17 July 2012 14:43, Andrew Dunstan <andrew@dunslane.net> wrote: >> This seems to have broken Windows builds. (And if people need reminding, >> cross-compiling is pretty easy: >> <http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html> >> ) > Perhaps I'm asking a naive question, but wouldn't it be easier if > people had the opportunity to use the buildfarm without actually > committing something? For example, perhaps the buildfarm could be made > to run on a staging branch. Commits would actually be made to the > staging branch. If and when the regression tests pass, the > infrastructure then pushes the staging branch commit onto the master > branch, and the commit is really committed - the -commiters list is > now informed of this. If there is a problem with the buildfarm, the > committer receives an e-mail informing them of this. The commit is > non-destructively reverted on the staging branch. > > I don't know that it's worth worrying about, nor if the turnaround on > having a commit not break the buildfarm would be generally acceptable > in this situation. It would be nice to keep commit history cleaner, > though. > I don't think we have so much breakage that it would be worth the bother. We don't use public staging branches generally, and unless people want to start doing so for other reasons this looks like more work than it would save. There is provision in the buildfarm client code for some hooks that could be used to apply and test patches. I've never used it for that but in theory it should be possible. cheers andrew
Peter Geoghegan <peter@2ndquadrant.com> writes:
> Perhaps I'm asking a naive question, but wouldn't it be easier if
> people had the opportunity to use the buildfarm without actually
> committing something?
Why? The whole point of the buildfarm is to break, as it were.
I don't see the value of adding more bureaucracy in order to keep
it from breaking.
regards, tom lane