Re: plpgsql merge func question - Mailing list pgsql-novice

From Matthias Leopold
Subject Re: plpgsql merge func question
Date
Msg-id 52B83948.8010308@aic.at
Whole thread Raw
In response to Re: plpgsql merge func question  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-novice
Am 2013-12-20 21:03, schrieb Merlin Moncure:
> 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
>
>
thank you very much, it was indeed a non-'unique_violation'...

matthias


pgsql-novice by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: plpgsql merge func question
Next
From: Shiv Sharma
Date:
Subject: Checkpoint versus Background Writer