Re: timeout implementation issues

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: timeout implementation issues
Date: 2002-04-01 17:48:45
Message-ID: 200204011748.g31Hmj629611@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I think there are two ways of making this capability visible to users.
> > First, you could do:
> >
> > SET query_timeout = 5;
> >
> > and all queries after that would time out at 5 seconds. Another option
> > is:
> >
> > BEGIN WORK TIMEOUT 5;
> > ...
> > COMMIT;
> >
> > which would make the transaction timeout after 5 seconds. We never
> > decided which one we wanted, or both.
>
> Note that the first is a statement-level timeout and the second is a
> transaction-level timeout. Be sure to clarify which one we want.

Oh, wow, that is an interesting distinction. If there is a multi-query
transaction, do we time each query separately or the entire transaction?
I don't know which people want, and maybe this is why we need both GUC
and BEGIN WORK timeouts. I don't remember this distinction in previous
discussions but it may be significant. Of course, the GUC could behave
at a transaction level as well. It will be tricky to manage multiple
alarms in a single process, but it can be done by creating an alarm
queue.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-01 17:50:52 Re: RI triggers and schemas
Previous Message Stephan Szabo 2002-04-01 17:42:20 Re: RI triggers and schemas