Re: plpgsql merge func question
От | Merlin Moncure |
---|---|
Тема | Re: plpgsql merge func question |
Дата | |
Msg-id | CAHyXU0yVh+xRQ5dc7njH4y9SmSSgPg0BoTUO=okuK+g3M_kRmQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql merge func question (Andreas Kretschmer <akretschmer@spamfence.net>) |
Ответы |
Re: plpgsql merge func question
Re: plpgsql merge func question |
Список | pgsql-novice |
On Fri, Dec 20, 2013 at 6:42 AM, Andreas Kretschmer <akretschmer@spamfence.net> wrote: > Matthias Leopold <matthias@aic.at> wrote: > >> hi, >> >> i tried to write a merge function in plpgsql, which is derived from the >> example in the docs (Example 38-2 in >> http://www.postgresql.org/docs/8.4/static/plpgsql-control-structures.html). >> Code is below. This works fine as long as entries in count_table have >> todays date in "datum". when i have older entries the function "locks >> up" (doesn't return, server has 100% cpu). i'm a plpgsql novice. can >> someone explain why this happens? related question: i didn't find a way > > Can't reproduce, works for me. Almost certainly a non-'unique_violation' exception is being thrown (perhaps from a dependent trigger). In a loop like that there should always be a handler of last resort. I bitterly griped about this example a few years back (search the archives). TBH, many times I've wished that caught-but-unhandled exceptions were re-thrown by default. Unless high concurrency is needed, for merge functionality it makes a lot more sense to just lock the table before the insert instead of rigging a loop. merlin
В списке pgsql-novice по дате отправления: