From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Henryk Szal <szal(at)doctorq(dot)com(dot)pl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: timeout on lock feature |
Date: | 2001-04-17 08:26:25 |
Message-ID: | 11C1E6749A55D411A9670001FA68796336828A@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I was thinking SET because UPDATE does an auto-lock.
Optimal would imho be a SET that gives a maximum amount of time in seconds
the client is willing to wait for any lock. But I liked the efficiency of Henryk's code.
>
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > I can imagine some people wanting this. However, 7.1 has new deadlock
> > > detection code, so I would you make a 7.1 version and send it over. We
> > > can get it into 7.2.
> >
> > I object strongly to any such "feature" in the low-level form that
> > Henryk proposes, because it would affect *ALL* locking. Do you really
> > want all your other transactions to go belly-up if, say, someone vacuums
> > pg_class?
Yes, if a non batch client already blocked for over x seconds. Of course a more
sophisticated client can send querycancel() but that involves a more complicated
program (threads, timer ...).
> >
> > A variant of LOCK TABLE that explicitly requests a timeout might make
> > sense, though.
I do not think that a solution for one particular lock is very helpful. If your dml then
blocks on some unforseen lock (parse, plan ...) , the client is in exactly the situation
it tried to avoid in the first place.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Henryk Szal | 2001-04-17 08:44:12 | Re: timeout on lock feature |
Previous Message | Lehel Gyuro | 2001-04-17 08:04:05 | plpgsql problem |