| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, Henryk Szal <szal(at)doctorq(dot)com(dot)pl>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | RE: AW: timeout on lock feature |
| Date: | 2001-04-17 17:14:25 |
| Message-ID: | 8F4C99C66D04D4118F580090272A7A234D33AB@sectorbase1.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Added to TODO:
> > * Add SET parameter to timeout if waiting for lock too long
>
> I repeat my strong objection to any global (ie, affecting all locks)
> timeout. Such a "feature" will have unpleasant consequences.
But LOCK TABLE T IN ROW EXCLUSIVE MODE WITH TIMEOUT X will not give
required results not only due to parser/planner locks - what if
UPDATE T will have to wait for other transactions commit/abort
(same row update)? Lock on pseudo-table is acquired in this case...
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alessio Bragadini | 2001-04-17 17:14:29 | Re: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A |
| Previous Message | Tom Lane | 2001-04-17 16:57:53 | Re: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A |