From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Barry Lind <barry(at)xythos(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <janwieck(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timeout implementation issues |
Date: | 2002-04-04 02:48:21 |
Message-ID: | 3CABBEF5.BC06B4CF@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>
> > > > The current plan seems to be to make changes in the backend and the JDBC
> > > > interface, the bulk of the implementation being in the backend.
> > >
> > > Yes, ODBC and JDBC need this, and I am sure psql folks will use it too,
> > > not counting libpq and all the others.
> >
> > I wasn't able to follow this thread sorry.
> > ODBC has QUERY_TIMEOUT and CONNECTION_TIMEOUT.
> >
> > > We just need a way to specify statement-level SET options inside a
> > > transaction where the statement may fail and ignore the SET command that
> > > resets the timeout. We don't have any mechanism to reset the timeout
> > > parameter at the end of a transaction automatically,
> >
> > Why should the timeout be reset automatically ?
>
> It doesn't need to be reset automatically, but the problem is that if
> you are doing a timeout for single statement in a transaction, and that
> statement aborts the transaction, the SET command after it to reset the
> timeout fails.
As for ODBC, there's no state that *abort* but still inside
a transaction currently.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2002-04-04 03:41:05 | What's the CURRENT schema ? |
Previous Message | Bruce Momjian | 2002-04-04 02:21:53 | Re: timeout implementation issues |