Re: NO WAIT ...
От | Bruce Momjian |
---|---|
Тема | Re: NO WAIT ... |
Дата | |
Msg-id | 200402181858.i1IIwBf24047@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: NO WAIT ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> Why? You can do a SELECT FOR UPDATE first and then you know that you > >> have the row lock. There's no need for any special handling of UPDATE > >> or DELETE. I don't see the applicability to VACUUM, either. > > > Why bother when you can do it without the SELECT FOR UPDATE? > > Because you want the extra feature? > > > It throws an error. I don't see how that could cause actual data > > corruption or invalid data. > > I am concerned about what behavior will stop working nicely when locks > that normally always succeed suddenly error out instead. Perhaps it > won't corrupt your database, but that doesn't mean that the behavior > will be pleasant. > > As an example: the proposed patch is able to cause an error instead of > waiting for access-share locks. Suppose you actually turn that on, and > then try to call some function, and the resulting attempt to read > pg_proc errors out because someone was transiently holding a conflicting > lock. This means your application fails, randomly, and in > hard-to-reproduce ways. Not only would the failure or not-failure > depend on what other people were doing, it'd depend on whether you'd > already cached the function definition (if so, no lock would actually > get taken on pg_proc during the call). > > I think a feature narrowly focused on suppressing waits for specific > locks (like the lock on a specific row that you're trying to update) > would be useful. Implementing something that affects *every* lock in > the system is nothing more nor less than a foot-gun, because you could > never be very certain what lock attempts would fail. The original idea I had was for the GUC variable to affect only exclusive locks. If we want more, we can add it later. I agree the extra GUC which controls the types of locks we will nowait for seems pretty useless. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: