From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthias Apitz <guru(at)unixarea(dot)de> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: ESQL/C: a ROLLBACK rolls back a COMMITED transaction |
Date: | 2020-05-12 15:54:40 |
Message-ID: | 23100.1589298880@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Matthias Apitz <guru(at)unixarea(dot)de> 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?
> 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
enabling log_statement = all so you can get a trace of what the server
thinks is happening.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tory M Blue | 2020-05-12 16:40:19 | Re: Is there a significant difference in Memory settings between 9.5 and 12 |
Previous Message | Michael Lewis | 2020-05-12 15:51:27 | Re: Hash partitioning, what function is used to compute the hash? |