| 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: | Paulo Scardine <paulos(at)cimed(dot)ind(dot)br>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SELECT FOR UPDATE NOWAIT |
| Date: | 2003-07-23 19:30:33 |
| Message-ID: | 200307231930.h6NJUXE11914@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "Paulo Scardine" <paulos(at)cimed(dot)ind(dot)br> writes:
> > - Where is the best place to put this?
>
> I think it would be a really *bad* idea to put it in LockAcquire; that
> risks breaking things that you don't want broken.
>
> Whether it's special syntax or a GUC variable, the restriction should
> only apply to SELECT FOR UPDATE row locks, perhaps user-commanded LOCK
> TABLE operations, and maybe one or two other places that are known to
> be used only for user-written operations and not for system-initiated
> ones. Those places would need to check whether to do a conditional
> or unconditional lock.
My original idea was to have it apply only for exclusive locks. It
seemed those were mostly the locks didn't want to wait for. Shared
locking pg_class is something that you would want to wait for.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2003-07-23 19:31:38 | Re: Feature request -- Log Database Name |
| Previous Message | Jenny - | 2003-07-23 19:27:02 | how do i turn off the html tags?? |