Re: lock_timeout GUC patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Subject: Re: lock_timeout GUC patch
Date: 2010-01-20 03:07:35
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> we already have statement timeout it seems the natural easy to implement
> this is with more hairy logic to calculate the timeout until the next of the
> three timeouts should fire and set sigalarm. I sympathize with whoever tries
> to work that through though, the logic is hairy enough with just the two
> variables...but at least we know that sigalarm works or at least it had
> better...

Yeah, that code is ugly as sin already. Maybe there is a way to
refactor it so it can scale better? I can't help thinking of Polya's
inventor's paradox ("the more general problem may be easier to solve").

If we want to do it without any new system-call dependencies I think
that's probably the only way. I'm not necessarily against new
dependencies, if they're portable --- but it seems these aren't.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2010-01-20 03:43:44 XQuery support
Previous Message Greg Sabino Mullane 2010-01-20 02:56:27 Re: MySQL-ism help patch for psql