Thread: psycopg2: proper positioning of .commit() within try: except: blocks
Dear all,
unto now I had been thinking this is a wise idiom (in code
that needs not care whether it fails to do what it tries to
do^1):
conn = psycopg2.connection(...)
curs = conn.cursor()
try:
curs.execute(SOME_SQL)
except PSYCOPG2-Exception:
some logging being done, and, yes, I
can safely inhibit propagation^1
finally:
conn.commit() # will rollback, if SOME_SQL failed
conn.close()
So today I head to learn that conn.commit() may very well
raise a DB related exception, too:
psycopg2.errors.SerializationFailure: could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
TIP: The transaction might succeed if retried.
Now, what is the proper placement of the .commit() ?
(doing "with ... as conn:" does not free me of committing appropriately)
Should I
try:
curs.execute(SOME_SQL)
conn.commit()
except PSYCOPG2-Exception:
some logging being done, and, yes, I
can safely inhibit propagation^1
finally:
conn.close() # which should .rollback() automagically in case we had not reached to .commit()
?
Thanks for insights,
Karsten
#-------------------------------
^1:
This particular code is writing configuration defaults
supplied in-code when no value is yet to be found in the
database. If it fails, no worries, the supplied default
is used by follow-on code and storing it is re-tried next
time around.
#-------------------------------
Exception details:
Traceback (most recent call last):
File "/usr/share/gnumed/Gnumed/wxpython/gmGuiMain.py", line 3472, in OnInit
frame = gmTopLevelFrame(None, id = -1, title = _('GNUmed client'), size = (640, 440))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/gnumed/Gnumed/wxpython/gmGuiMain.py", line 191, in __init__
self.LayoutMgr = gmHorstSpace.cHorstSpaceLayoutMgr(self, -1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/gnumed/Gnumed/wxpython/gmHorstSpace.py", line 215, in __init__
self.top_panel = gmTopPanel.cTopPnl(self, -1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/gnumed/Gnumed/wxpython/gmTopPanel.py", line 52, in __init__
wxgTopPnl.wxgTopPnl.__init__(self, *args, **kwargs)
File "/usr/share/gnumed/Gnumed/wxGladeWidgets/wxgTopPnl.py", line 33, in __init__
self._TCTRL_patient_selector = cActivePatientSelector(self, wx.ID_ANY, "")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/gnumed/Gnumed/wxpython/gmPatSearchWidgets.py", line 1295, in __init__
cfg.get2 (
File "/usr/share/gnumed/Gnumed/pycommon/gmCfg.py", line 248, in get2
self.set (
File "/usr/share/gnumed/Gnumed/pycommon/gmCfg.py", line 367, in set
rw_conn.commit() # will rollback if transaction failed
^^^^^^^^^^^^^^^^
psycopg2.errors.SerializationFailure: could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
TIP: The transaction might succeed if retried.
2024-08-20 22:17:04 INFO gm.cfg [140274204403392 UpdChkThread-148728]
(/usr/share/gnumed/Gnumed/pycommon/gmCfg.py::get2()#148): creating option [horstspace.update.consider_latest_branch]
withdefault [True]
2024-08-20 22:17:04 DEBUG gm.db_pool [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmConnectionPool.py::exception_is_connection_loss()#667): interpreting: could not
serializeaccess due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
TIP: The transaction might succeed if retried.
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#170): exception: could not serialize access due to
read/writedependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
TIP: The transaction might succeed if retried.
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#171): type: <class
'psycopg2.errors.SerializationFailure'>
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#172): list of attributes:
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): add_note: <built-in method add_note of
SerializationFailureobject at 0x7f942a3c9cf0>
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): args: ('could not serialize access due to
read/writedependencies among transactions\nDETAIL: Reason code: Canceled on identification as a pivot, during commit
attempt.\nTIP: The transaction might succeed if retried.\n',)
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): cursor: None
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): diag: <psycopg2.extensions.Diagnostics object
at0x7f942a2b9e10>
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): pgcode: 40001
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): pgerror: ERROR: could not serialize access due
toread/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
TIP: The transaction might succeed if retried.
2024-08-20 22:17:04 DEBUG gm.logging [140274459512896 MainThread]
(/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace()#178): with_traceback: <built-in method with_traceback
ofSerializationFailure object at 0x7f942a3c9cf0>
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On 9/7/24 08:48, Karsten Hilbert wrote: > Dear all, > > unto now I had been thinking this is a wise idiom (in code > that needs not care whether it fails to do what it tries to > do^1): > > conn = psycopg2.connection(...) In the above do you have: https://www.psycopg.org/docs/extensions.html#psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE Or is that in some other concurrent transaction? > curs = conn.cursor() > try: > curs.execute(SOME_SQL) > except PSYCOPG2-Exception: > some logging being done, and, yes, I > can safely inhibit propagation^1 > finally: > conn.commit() # will rollback, if SOME_SQL failed It will if you use with conn:, otherwise it up to you to do the rollback() Are you are doing a rollback() in except PSYCOPG2-Exception: ? -- Adrian Klaver adrian.klaver@aklaver.com
Am Sat, Sep 07, 2024 at 09:46:03AM -0700 schrieb Adrian Klaver: > >unto now I had been thinking this is a wise idiom (in code > >that needs not care whether it fails to do what it tries to > >do^1): > > > > conn = psycopg2.connection(...) > > In the above do you have: > > https://www.psycopg.org/docs/extensions.html#psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE > > psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE I do indeed. > Or is that in some other concurrent transaction? In fact in that codebase all transactions -- running concurrently or not -- are set to SERIALIZABLE. They are not psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT, for that matter. > > curs = conn.cursor() > > try: > > curs.execute(SOME_SQL) > > except PSYCOPG2-Exception: > > some logging being done, and, yes, I > > can safely inhibit propagation^1 > > finally: > > conn.commit() # will rollback, if SOME_SQL failed > > It will if you use with conn:, otherwise it up to you to do the rollback() > > Are you are doing a rollback() in except PSYCOPG2-Exception: ? No I don't but - to my understanding - an ongoing transaction is being closed upon termination of the hosting connection. Unless .commit() is explicitely being issued somewhere in the code that closing of a transaction will amount to a ROLLBACK. In case of SQL having failed within a given transaction a COMMIT will fail-but-rollback, too (explicit ROLLBACK would succeed while a COMMIT would fail and, in-effect, roll back). IOW, when SOME_SQL has failed it won't matter that I close the connection with conn.commit() and it won't matter that conn.commit() runs a COMMIT on the database -- an open transaction having run that failed SQL will still roll back as if ROLLBACK had been issued. Or else my mental model is wrong. https://www.psycopg.org/docs/connection.html#connection.close In the particular case I was writing about the SQL itself succeeded but then the COMMIT failed due to serialization. I was wondering about where to best place any needed conn.commit(). My knee-jerk reaction was to then put it last in the try: block... All this is probably more related to Python than to PostgreSQL. Thanks, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On 9/7/24 12:44, Karsten Hilbert wrote: > Am Sat, Sep 07, 2024 at 09:46:03AM -0700 schrieb Adrian Klaver: > > No I don't but - to my understanding - an ongoing transaction > is being closed upon termination of the hosting connection. > Unless .commit() is explicitely being issued somewhere in the > code that closing of a transaction will amount to a ROLLBACK. > > In case of SQL having failed within a given transaction a > COMMIT will fail-but-rollback, too (explicit ROLLBACK would > succeed while a COMMIT would fail and, in-effect, roll back). > > IOW, when SOME_SQL has failed it won't matter that I close > the connection with conn.commit() and it won't matter that > conn.commit() runs a COMMIT on the database -- an open > transaction having run that failed SQL will still roll back > as if ROLLBACK had been issued. Or else my mental model is > wrong. > > https://www.psycopg.org/docs/connection.html#connection.close Which says: " Note that closing a connection without committing the changes first will cause any pending change to be discarded as if a ROLLBACK was performed" That indicates the ROLLBACK is done on the close() not the commit() and only if a commit() was not issued first. NOTE: If you use the with context manager the transaction automatically commits on success and rolls back exception, though it does not close the connection. This is changed in psycopg3 where the connection is closed In the case you show you are doing commit() before the close() so any errors in the transactions will show up then. My first thought would be to wrap the commit() in a try/except and deal with error there. > > In the particular case I was writing about the SQL itself > succeeded but then the COMMIT failed due to serialization. I > was wondering about where to best place any needed > conn.commit(). My knee-jerk reaction was to then put it last > in the try: block... > > All this is probably more related to Python than to PostgreSQL. > > Thanks, > Karsten > -- > GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- Adrian Klaver adrian.klaver@aklaver.com
Am Sat, Sep 07, 2024 at 01:03:34PM -0700 schrieb Adrian Klaver:
> In the case you show you are doing commit() before the close() so any errors in the
> transactions will show up then. My first thought would be to wrap the commit() in a
> try/except and deal with error there.
Right, and this was suggested elsewhere ;)
And, yeah, the actual code is much more involved :-D
#------------------------------------------------------------------------
def __safely_close_cursor_and_rollback_close_conn(close_cursor=None, rollback_tx=None, close_conn=None):
if close_cursor:
try:
close_cursor()
except PG_ERROR_EXCEPTION as pg_exc:
_log.exception('cannot close cursor')
gmConnectionPool.log_pg_exception_details(pg_exc)
if rollback_tx:
try:
# need to rollback so ABORT state isn't retained in pooled connections
rollback_tx()
except PG_ERROR_EXCEPTION as pg_exc:
_log.exception('cannot rollback transaction')
gmConnectionPool.log_pg_exception_details(pg_exc)
if close_conn:
try:
close_conn()
except PG_ERROR_EXCEPTION as pg_exc:
_log.exception('cannot close connection')
gmConnectionPool.log_pg_exception_details(pg_exc)
#------------------------------------------------------------------------
def run_rw_queries (
link_obj:_TLnkObj=None,
queries:_TQueries=None,
end_tx:bool=False,
return_data:bool=None,
get_col_idx:bool=False,
verbose:bool=False
) -> tuple[list[dbapi.extras.DictRow], dict[str, int] | None]:
"""Convenience function for running read-write queries.
Typically (part of) a transaction.
Args:
link_obj: None, cursor, connection
queries:
* a list of dicts [{'cmd': <string>, 'args': <dict> or <tuple>)
* to be executed as a single transaction
* the last query may usefully return rows, such as:
SELECT currval('some_sequence');
or
INSERT/UPDATE ... RETURNING some_value;
end_tx:
* controls whether the transaction is finalized (eg.
COMMITted/ROLLed BACK) or not, this allows the
call to run_rw_queries() to be part of a framing
transaction
* if link_obj is a *connection* then "end_tx" will
default to False unless it is explicitly set to
True which is taken to mean "yes, you do have full
control over the transaction" in which case the
transaction is properly finalized
* if link_obj is a *cursor* we CANNOT finalize the
transaction because we would need the connection for that
* if link_obj is *None* "end_tx" will, of course, always
be True, because we always have full control over the
connection, not ending the transaction would be pointless
return_data:
* if true, the returned data will include the rows
the last query selected
* if false, it returns None instead
get_col_idx:
* True: the returned tuple will include a dictionary
mapping field names to column positions
* False: the returned tuple includes None instead of a field mapping dictionary
Returns:
* (None, None) if last query did not return rows
* ("fetchall() result", <index>) if last query returned any rows and "return_data" was True
* for *index* see "get_col_idx"
"""
assert queries is not None, '<queries> must not be None'
if link_obj is None:
conn = get_connection(readonly = False)
curs = conn.cursor()
conn_close = conn.close
tx_commit = conn.commit
tx_rollback = conn.rollback
curs_close = curs.close
notices_accessor = conn
else:
conn_close = lambda *x: None
tx_commit = lambda *x: None
tx_rollback = lambda *x: None
curs_close = lambda *x: None
if isinstance(link_obj, dbapi._psycopg.cursor):
curs = link_obj
notices_accessor = curs.connection
elif isinstance(link_obj, dbapi._psycopg.connection):
if end_tx:
tx_commit = link_obj.commit
tx_rollback = link_obj.rollback
curs = link_obj.cursor()
curs_close = curs.close
notices_accessor = link_obj
else:
raise ValueError('link_obj must be cursor, connection or None but not [%s]' % link_obj)
for query in queries:
try:
args = query['args']
except KeyError:
args = None
try:
curs.execute(query['cmd'], args)
if verbose:
gmConnectionPool.log_cursor_state(curs)
for notice in notices_accessor.notices:
_log.debug(notice.replace('\n', '/').replace('\n', '/'))
del notices_accessor.notices[:]
# DB related exceptions
except dbapi.Error as pg_exc:
_log.error('query failed in RW connection')
gmConnectionPool.log_pg_exception_details(pg_exc)
for notice in notices_accessor.notices:
_log.debug(notice.replace('\n', '/').replace('\n', '/'))
del notices_accessor.notices[:]
__safely_close_cursor_and_rollback_close_conn (
curs_close,
tx_rollback,
conn_close
)
# privilege problem ?
if pg_exc.pgcode == PG_error_codes.INSUFFICIENT_PRIVILEGE:
details = 'Query: [%s]' % curs.query.decode(errors = 'replace').strip().strip('\n').strip().strip('\n')
if curs.statusmessage != '':
details = 'Status: %s\n%s' % (
curs.statusmessage.strip().strip('\n').strip().strip('\n'),
details
)
if pg_exc.pgerror is None:
msg = '[%s]' % pg_exc.pgcode
else:
msg = '[%s]: %s' % (pg_exc.pgcode, pg_exc.pgerror)
raise gmExceptions.AccessDenied (
msg,
source = 'PostgreSQL',
code = pg_exc.pgcode,
details = details
)
# other DB problem
gmLog2.log_stack_trace()
raise
# other exception
except Exception:
_log.exception('error running query in RW connection')
gmConnectionPool.log_cursor_state(curs)
for notice in notices_accessor.notices:
_log.debug(notice.replace('\n', '/').replace('\n', '/'))
del notices_accessor.notices[:]
gmLog2.log_stack_trace()
__safely_close_cursor_and_rollback_close_conn (
curs_close,
tx_rollback,
conn_close
)
raise
data = None
col_idx = None
if return_data:
try:
data = curs.fetchall()
except Exception:
_log.exception('error fetching data from RW query')
gmLog2.log_stack_trace()
__safely_close_cursor_and_rollback_close_conn (
curs_close,
tx_rollback,
conn_close
)
raise
if get_col_idx:
col_idx = get_col_indices(curs)
curs_close()
tx_commit()
conn_close()
return (data, col_idx)
#------------------------------------------------------------------------
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On 9/7/24 13:45, Karsten Hilbert wrote: > Am Sat, Sep 07, 2024 at 01:03:34PM -0700 schrieb Adrian Klaver: > >> In the case you show you are doing commit() before the close() so any errors in the >> transactions will show up then. My first thought would be to wrap the commit() in a >> try/except and deal with error there. > > Right, and this was suggested elsewhere ;) > > And, yeah, the actual code is much more involved :-D > I see that. The question is does the full code you show fail? The code sample you show in your original post is doing something very different then what you show in your latest post. At this point I do not understand the exact problem we are dealing with. > > > Best, > Karsten > -- > GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- Adrian Klaver adrian.klaver@aklaver.com
Am Sat, Sep 07, 2024 at 02:09:28PM -0700 schrieb Adrian Klaver:
> >Right, and this was suggested elsewhere ;)
> >
> >And, yeah, the actual code is much more involved :-D
> >
>
> I see that.
>
> The question is does the full code you show fail?
>
> The code sample you show in your original post is doing something very different then
> what you show in your latest post. At this point I do not understand the exact problem
> we are dealing with.
We are not dealing with an unsolved problem. I had been
asking for advice where to best place that .commit() call in
case I am overlooking benefits and drawbacks of choices.
The
try:
do something
except:
log something
finally:
.commit()
cadence is fairly Pythonic and elegant in that it ensures the
the .commit() will always be reached regardless of exceptions
being thrown or not and them being handled or not.
It is also insufficient because the .commit() itself may
elicit exceptions (from the database).
So there's choices:
Ugly:
try:
do something
except:
log something
finally:
try:
.commit()
except:
log some more
Fair but not feeling quite safe:
try:
do something
.commit()
except:
log something
Boring and repetitive and safe(r):
try:
do something
except:
log something
try:
.commit()
except:
log something
I eventually opted for the last version, except for factoring
out the second try: except: block.
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On 9/7/24 14:20, Karsten Hilbert wrote: > Am Sat, Sep 07, 2024 at 02:09:28PM -0700 schrieb Adrian Klaver: > >>> Right, and this was suggested elsewhere ;) >>> >>> And, yeah, the actual code is much more involved :-D >>> >> >> I see that. >> >> The question is does the full code you show fail? >> >> The code sample you show in your original post is doing something very different then >> what you show in your latest post. At this point I do not understand the exact problem >> we are dealing with. > > We are not dealing with an unsolved problem. I had been > asking for advice where to best place that .commit() call in > case I am overlooking benefits and drawbacks of choices. > > The > > try: > do something > except: > log something > finally: > .commit() > > cadence is fairly Pythonic and elegant in that it ensures the > the .commit() will always be reached regardless of exceptions > being thrown or not and them being handled or not. Elegant is nice, but correct is better:) > > It is also insufficient because the .commit() itself may > elicit exceptions (from the database). Yeah with Serializable that is part of the package: "While PostgreSQL's Serializable transaction isolation level only allows concurrent transactions to commit if it can prove there is a serial order of execution that would produce the same effect ..." > Boring and repetitive and safe(r): > > try: > do something > except: > log something > try: > .commit() > except: > log something > > I eventually opted for the last version, except for factoring > out the second try: except: block. I'm not following, if you do that then you won't have a commit. > > Best, > Karsten > -- > GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- Adrian Klaver adrian.klaver@aklaver.com
Am Sat, Sep 07, 2024 at 02:47:49PM -0700 schrieb Adrian Klaver:
> >It is also insufficient because the .commit() itself may
> >elicit exceptions (from the database).
>
> Yeah with Serializable that is part of the package:
No complaints :-)
> > try:
> > do something
> > except:
> > log something
> > try:
> > .commit()
> > except:
> > log something
> >
> >I eventually opted for the last version, except for factoring
> >out the second try: except: block.
>
> I'm not following, if you do that then you won't have a commit.
Perhaps my pseudo-code was to abbreviated.
conn = psycopg2.connection()
curs = conn.cursor()
curs.execute(SQL)
curs.close()
conn.commit()
conn.close()
Written more safely:
conn = psycopg2.connection()
curs = conn.cursor()
try:
curs.execute(SQL)
except SOME_PG_EXCEPTION_VIA_PSYCOPG2:
some_panicstricken_logging()
curs.close()
try:
conn.commit()
except SOME_PG_EXCEPTION_VIA_PSYCOPG2__SUCH_AS_SERIALIZATION_ERROR:
some_more_of_the_panicstricken_logging()
conn.close()
now factored out:
def __commit_me_logging_errors(commit_func):
try:
commit_func()
except SOME_PG_EXCEPTION_VIA_PSYCOPG2__SUCH_AS_SERIALIZATION_ERROR:
some_more_of_the_panicstricken_logging()
return
conn = psycopg2.connection()
curs = conn.cursor()
try:
curs.execute(SQL)
except SOME_PG_EXCEPTION_VIA_PSYCOPG2:
some_panicstricken_logging()
curs.close()
__commit_me_logging_errors(conn.commit)
conn.close()
More clear ?
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
On 9/7/24 14:59, Karsten Hilbert wrote: > Am Sat, Sep 07, 2024 at 02:47:49PM -0700 schrieb Adrian Klaver: > >>> It is also insufficient because the .commit() itself may >>> elicit exceptions (from the database). >> >> Yeah with Serializable that is part of the package: > > No complaints :-) > > >>> try: >>> do something >>> except: >>> log something >>> try: >>> .commit() >>> except: >>> log something >>> >>> I eventually opted for the last version, except for factoring >>> out the second try: except: block. >> >> I'm not following, if you do that then you won't have a commit. > > Perhaps my pseudo-code was to abbreviated. > > conn = psycopg2.connection() > curs = conn.cursor() > curs.execute(SQL) > curs.close() > conn.commit() > conn.close() > > Written more safely: > > conn = psycopg2.connection() > curs = conn.cursor() > try: > curs.execute(SQL) > except SOME_PG_EXCEPTION_VIA_PSYCOPG2: > some_panicstricken_logging() > curs.close() > try: > conn.commit() > except SOME_PG_EXCEPTION_VIA_PSYCOPG2__SUCH_AS_SERIALIZATION_ERROR: > some_more_of_the_panicstricken_logging() > conn.close() > > now factored out: > > def __commit_me_logging_errors(commit_func): > try: > commit_func() > except SOME_PG_EXCEPTION_VIA_PSYCOPG2__SUCH_AS_SERIALIZATION_ERROR: > some_more_of_the_panicstricken_logging() > return > > conn = psycopg2.connection() > curs = conn.cursor() > try: > curs.execute(SQL) > except SOME_PG_EXCEPTION_VIA_PSYCOPG2: > some_panicstricken_logging() > curs.close() > __commit_me_logging_errors(conn.commit) > conn.close() > > More clear ? Yes. > > Karsten > -- > GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- Adrian Klaver adrian.klaver@aklaver.com