On 11/18/15 2:42 PM, Jeff Janes wrote:
But he already knows it has race conditions. That is why he included
retry logic, to deal with those conditions.
From the sounds of it there's no retry loop, which means there's still
a race condition (data is deleted after insert fails but before update).
>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.
Meh. Not like there's that much to learning plpgsql if you already know
plpgsql.
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.
Really we need much more granular logging control, period. The lack of
it makes RAISE DEBUG in anything but the most trivial environments
completely useless.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
