Tomasz Myrta wrote:
> Christoph Haller wrote:
>
> > Yupp, I agree.
> > But from former DBMS I was dealing with,
> > I know this SET TIMEOUT called feature, which if properly set
> > terminated processes like that hanging on T2.
> > Is there something comparable within Postgres?
>
> PostgreSQL 7.3
>
> PostgreSQL 7.3 Documentation
> 3.4. Run-time Configuration
> STATEMENT_TIMEOUT (integer)
> Aborts any statement that takes over the specified number of
milliseconds. A value of zero turns off the timer.
> DEADLOCK_TIMEOUT (integer)
> This is the amount of time, in milliseconds, to wait on a loc
Christoph Haller wrote:
Yupp, I agree.
But from former DBMS I was dealing with,
I know this SET TIMEOUT called feature, which if properly set
terminated processes like that hanging on T2.
Is there something comparable within Postgres?
PostgreSQL 7.3 Documentation
3.4. Run-time Configuration
ST
> >
> > T1 (within psql):
> > BEGIN; DELETE FROM ;
> > DELETE n
> >
> > T2 (within psql):
> > BEGIN; DELETE FROM ;
> >
> >
...
>
>I don't think there is a deadlock in the example
> given above. If I'm not mistaken a deadlock occurs if
> both transactions are waiting for each other to
> relea
--- Christoph Haller <[EMAIL PROTECTED]> wrote:
>
> I'm working on
> PostgreSQL 7.2.3 on hppa-hp-hpux10.20, compiled by
> GCC 2.95.2
> and found a similar behaviour.
>
> T1 (within psql):
> BEGIN; DELETE FROM ;
> DELETE n
>
> T2 (within psql):
> BEGIN; DELETE FROM ;
>
>
> The documentation
>
> I have recently migrated my database from MS Sql
> Server to postgresql 7.3.1. In MS SQL SERVER, it is
> very easy to set the lock time equals to zero on ROW
> LEVEL. So that if some other user try to access the
> same data, he/she will get the error immediately. I
> have tried to run the same
