Re: plpgsql merge func question

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andreas Kretschmer <akretschmer(at)spamfence(dot)net>
Cc: pgsql novice <pgsql-novice(at)postgresql(dot)org>
Subject: Re: plpgsql merge func question
Date: 2013-12-20 20:03:59
Message-ID: CAHyXU0yVh+xRQ5dc7njH4y9SmSSgPg0BoTUO=okuK+g3M_kRmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

On Fri, Dec 20, 2013 at 6:42 AM, Andreas Kretschmer
<akretschmer(at)spamfence(dot)net> wrote:
> Matthias Leopold <matthias(at)aic(dot)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

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Merlin Moncure 2013-12-21 03:11:24 Re: plpgsql merge func question
Previous Message Алексей Кузнецов 2013-12-20 12:58:36 Strange number of rows in plan cost