Re: [PATCHES] NO WAIT ...
От | Barry Lind |
---|---|
Тема | Re: [PATCHES] NO WAIT ... |
Дата | |
Msg-id | 4033C095.9070205@xythos.com обсуждение исходный текст |
Ответ на | Re: [PATCHES] NO WAIT ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] NO WAIT ...
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [PATCHES] NO WAIT ... (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
I agree with Tom here. I have used the Oracle NOWAIT feature in the past and think it is a great feature IMHO. But when you need to use it, you want it to apply very specifically to a single statement. Using a sledge hammer when you need a tweezers isn't the right way to go. thanks, --Barry Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >>The question is whether we should have a GUC variable to control no >>waiting on locks or add NO WAIT to specific SQL commands. > > > That's only a minor part of the issue. The major problem I have with > the patch is that it affects *all* locks, including system-internal > lock attempts that the user is probably not even aware of much less > able to control. It's like giving someone a poorly-aligned shotgun > when what they need is a rifle --- they'll end up putting holes in > a lot of other things besides what they intended. > > I think that what we actually want is something that is narrowly > tailored to affect only row-level locks taken by SELECT FOR UPDATE, > and maybe one or two other places that (a) people can make specific > use-cases for, and (b) we can be certain are only invoked by user > commands and never indirectly from behind-the-scenes system operations. > > The reason for proposing syntax rather than a GUC variable is the same > one of control. If you set a GUC variable then it will be hard to > prevent it from breaking operations other than the one you thought you > intended. (Example: you think you are only causing your SELECT FOR > UPDATE to error out, but what about ones done behind the scenes for > foreign key checks?) GUC variables are good for stuff that tends to > apply application-wide, which is why I thought regex_flavor wasn't too > dangerous, but they're terrible for functions that you want to apply to > only certain specific operations. And I can't imagine an app where that > wouldn't be true for NO WAIT. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html
В списке pgsql-hackers по дате отправления: