Abort transaction on duplicate key error

Hi all,
Sorry for bothering you with my stuff for the second time
but I haven't got any answer within two days and the problem
appears fundamental, at least to me.
I have a C application running to deal with meteorological data
like temperature, precipitation, wind speed, wind direction, ...
And I mean loads of data like several thousand sets within every
ten minutes.
>From time to time it happens the transmitters have delivered wrong data,
so they send the sets again to be taken as correction.
The idea is to create a unique index on the timestamp, the location id
and the measurement id, then when receiving a duplicate key error
move on to an update command on that specific row.
But, within PostgreSQL this strategy does not work any longer within
a chained transaction, because the duplicate key error leads to
'abort the whole transaction'.
What I can do is change from chained transaction to unchained transaction,
but what I have read in the mailing list so far, the commit operation
requires loads of cpu time, and I do not have time for this when
processing thousands of sets.
I am wondering now whether there is a fundamental design error in
my strategy.
Any ideas, suggestions highly appreciated and thanks for reading so far.
Regards, Christoph

My first message:
In a C application I want to run several
insert commands within a chained transaction
(for faster execution).
>From time to time there will be an insert command
causing an
ERROR: Cannot insert a duplicate key into a unique index

As a result, the whole transaction is aborted and all
the previous inserts are lost.
Is there any way to preserve the data
except working with "autocommit" ?
What I have in mind particularly is something like
"Do not abort on duplicate key error".