Re: timeout on lock feature

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: 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: Re: timeout on lock feature
Date: 2001-04-13 16:46:01
Message-ID: 200104131646.MAA09862@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I was thinking SET because UPDATE does an auto-lock.

> 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?
>
> A variant of LOCK TABLE that explicitly requests a timeout might make
> sense, though.
>
> regards, tom lane
>

--
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Patrick Welche 2001-04-13 16:48:51 Re: Call for platforms
Previous Message Tom Lane 2001-04-13 16:44:55 Re: timeout on lock feature