Re: duplicate key errors in log file - Mailing list pgsql-general

From Jeff Janes
Subject Re: duplicate key errors in log file
Date
Msg-id CAMkU=1xkz39K-RZd4_RaxVP7kmZMTK0UYAqotmF0v2SaCJ3MVA@mail.gmail.com
Whole thread Raw
In response to Re: duplicate key errors in log file  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: duplicate key errors in log file
List pgsql-general
On Wed, Nov 18, 2015 at 9:35 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 11/17/15 5:33 PM, anj patnaik wrote:
>>
>> The pg log files apparently log error lines every time a user inserts a
>> duplicate. I implemented a composite primary key and then when I see the
>> exception in my client app I update the row with the recent data.
>>
>> however, I don't want the log file to fill out with these error messages
>> since it's handled by the client.
>>
>> is there a way to stop logging certain messages?
>>
>> Also do any of you use any options to cause log files not to fill up the
>> disk over time?
>
>
> Not really. You could do something like SET log_min_messages = PANIC for
> that statement, but then you won't get a log for any other errors.
>
> In any case, the real issue is that you shouldn't do this in the client.
> I'll bet $1 that your code has race conditions.

But he already knows it has race conditions.  That is why he included
retry logic, to deal with those conditions.


> Even if you got rid of
> those, the overhead of the back-and-forth with the database is huge compared
> to doing this in the database.
>
> So really you should create a plpgsql function ala example 40-2 at
> http://www.postgresql.org/docs/9.4/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

It is pretty heavy handed to have to learn yet another language just
to deal with some rare condition which can be handled fine with one of
the languages you already know.

I would certainly welcome an optional way to turn off server logging
of errors of a racy nature, while still have things like syntax errors
get logged.

Cheers,

Jeff


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.
Next
From: Adrian Klaver
Date:
Subject: Re: postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.