not logging caught exceptions

Lists: pgsql-hackers
From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: not logging caught exceptions
Date: 2009-11-11 21:24:09
Message-ID: 1257974649.22025.34.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Is it at all reasonable to try to create some mechanism so that
exceptions (elog) that are caught and not rethrown do not end up in the
log? For example, when you write code that does something like

try
insert
catch unique_constraint_violation
update
end try

this will end up cluttering the logs with all the constraint violation
messages.

Now, we probably don't want to just suppress all logging in a TRY block
until the END_TRY. So maybe this could be an argument to TRY or a
separate statement that would typically be run right after TRY that
names exception types to handle specially. Higher level languages such
as PL/pgSQL could then peek ahead to the catch block to set this up.

Comments?


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: not logging caught exceptions
Date: 2009-11-12 00:45:33
Message-ID: 5834.1257986733@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Is it at all reasonable to try to create some mechanism so that
> exceptions (elog) that are caught and not rethrown do not end up in the
> log? For example, when you write code that does something like

> try
> insert
> catch unique_constraint_violation
> update
> end try

> this will end up cluttering the logs with all the constraint violation
> messages.

Really? It's not supposed to.

regards, tom lane


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: not logging caught exceptions
Date: 2009-11-12 13:57:34
Message-ID: 1258034254.26305.29.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On ons, 2009-11-11 at 19:45 -0500, Tom Lane wrote:
> > try
> > insert
> > catch unique_constraint_violation
> > update
> > end try
>
> > this will end up cluttering the logs with all the constraint violation
> > messages.
>
> Really? It's not supposed to.

There might be a different bug here. This doesn't look right:

CREATE LANGUAGE plpgsql;

CREATE TABLE keytest (a int PRIMARY KEY, b text);

CREATE OR REPLACE FUNCTION insert_or_update(new_a int, new_b text)
RETURNS text
LANGUAGE plpgsql
AS $$
BEGIN
INSERT INTO keytest VALUES (new_a, new_b);
RETURN 'inserted';
EXCEPTION
WHEN integrity_constraint_violation THEN
UPDATE keytest SET a = new_a, b = new_b;
RETURN 'updated';
END;
$$;

SELECT insert_or_update(1, 'one');
SELECT insert_or_update(1, 'one');
SELECT insert_or_update(2, 'two');
SELECT insert_or_update(2, 'two');

Results in:

insert_or_update
------------------
inserted
(1 row)

insert_or_update
------------------
updated
(1 row)

insert_or_update
------------------
inserted
(1 row)

ERROR: duplicate key value violates unique constraint "keytest_pkey"
CONTEXT: SQL statement "UPDATE keytest SET a = $1 , b = $2 "
PL/pgSQL function "insert_or_update" line 6 at SQL statement


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: not logging caught exceptions
Date: 2009-11-12 14:39:45
Message-ID: 23841.1258036785@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> There might be a different bug here. This doesn't look right:

The UPDATE lacks a WHERE clause :-(

regards, tom lane