To answer also the question of Adrian Klaver: The database in question has ~400 tables and the ESQL/C application has for each table its own ESQL/C source file. It would be possible but a nightmare to share the code and it's better to discuss the problem based on the ESQL/c log file or I have to write some small example code to reproduce the problem. The line numbers are relative to those source files (and it's a pitty that the name of the source file is not logged, onle the line numbers). El día Dienstag, Mai 12, 2020 a las 11:54:40 -0400, Tom Lane escribió: > Matthias Apitz <guru@xxxxxxxxxxx> writes: > > We're facing in our ESQL/C written application a situation where a > > commit'ed INSERT into a table is rolled back. > > Kind of hard to believe ... is there any sign of distress in the > postmaster log? No. Nothing which points to this. > > > I have here the ESQL/C > > logging of the problem: > > > ... > > [1471] [12.05.2020 15:48:50:476]: ecpg_execute on line 1744: query: insert into swd_daten ( katkey , aktion , reserv , id , ansetzung , nettodaten ) values ( $1 , $2 , $3 , $4 , $5 , $6 ); with 6 parameter(s) on connection sisis > > [1471] [12.05.2020 15:48:50:476]: ecpg_process_output on line 1744: OK: INSERT 0 1 > > [1471] [12.05.2020 15:48:50:477]: ECPGtrans on line 6716: action "commit"; connection "sisis" > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > It's striking that this log shows a server ack of the INSERT, but no server > ack of the COMMIT. Maybe that's just an oversight in the ESQL/C logging > logic, but I wonder what's actually getting to the server. You might try I looked into the source and the ECPGtrans ... is logged before its execution in the source interfaces/ecpg/ecpglib/misc.c and after the execution only an error condition would be logged. As there is only the line of the COMMIT w/o anything else, it seems to be executed fine. > enabling log_statement = all so you can get a trace of what the server > thinks is happening. I will do so, but would have to find a time window for this to not be swamped by the logs. Thanks for your reply to both, Adiran and Tom. matthias -- Matthias Apitz, ✉ guru@xxxxxxxxxxx, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
