daveg <[EMAIL PROTECTED]> writes:
> lock-timeout sets statement_timeout to a small value while locks are being
> taken on all the tables. Then it resets it to default. So it could reset it
> to whatever the new default is.
"reset to default" is *surely* not the right behavior; resetting to the
setting that had been in effect might be a bit sane. But the whole
design sounds pretty broken to start with. The timer management code
already understands the concept of scheduling the interrupt for the
nearest of a couple of potentially active timeouts. ISTM any patch
intended to add a feature like this ought to extend that logic rather
than hack around changing the values of global variables.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
