Search Postgresql Archives

Re: ESQL/C: a ROLLBACK rolls back a COMMITED transaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux