New info:
We could also reproduce it with Postgres 10.10 32bit on Windows Server 2016 and 9.6.8 64bit on Ubuntu (18.x). So also the 32bit version is affected, as well as 9.x versions.
Current test state:
We (2 of my colleagues and me) are currently trying to create an independent test, but at the moment it only occurrs within the specific application.
Of course we search for an error in the application first, checked the connection settings, tracked all statements... there is nothing special, only a handful of SELECTS and UPDATES, then the sequence generation and the (sometimes failing) INSERT, and another INSERT (no sequence generate here) and UPDATE following. In all cases we tested with the Postgres default configuration.
We could see that wrapping the selection of NEXTVAL() in a transaction (which shouldn't have any effect?) reduced the problem in one case, but it was still possible to reproduce the error with an increased number of requests.
At the moment we don't have a real idea how to proceed. Next step planned is to simulate all of the aforementioned requests done by the application, because they seem to influence the behavior.
Background:
The application is written in PHP (different versions used in the tests, 7.2 - 7.4 I guess), runs on Apache/IIS (FastCGI) and uses the PDO extension for the communication with Postgres.
Christoph
Am 20. August 2019 16:21:08 MESZ schrieb Merlin Moncure <mmoncure@gmail.com>:
On Tue, Aug 20, 2019 at 9:14 AM Jeff Janes <jeff.janes@gmail.com> wrote:
I did many tests:
Can you include the code which implements those tests?
I can't reproduce with something like this:
+1 this. This would be a very embarrassing and serious problem should
it be proven to be valid. We would however need to rule out issues
in the test code itself. The best possible approach in terms of
verification would be a .sql only test with reproduction via pgbench
-f (IMO).
merlin
