Postgres error message after startup

[Bewi42]

Hello,
I don't know if this really is an issue. I am running apicurio registry 2.1.4.Final with SQL storage on a Kube container. It connects to a postgres database.
The initialization steps look to begin correctly, but then I have an exception :

2021-12-17 12:24:49 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) SqlRegistryStorage constructed successfully.  JDBC URL: jdbc:postgresql://postgresql:5432/apicuriodb
2021-12-17 12:24:49 INFO <> [io.quarkus.bootstrap.runner.Timing] (main) apicurio-registry-storage-sql 2.1.4.Final on JVM (powered by Quarkus 2.2.3.Final) started in 18.799s. Listening on: http://0.0.0.0:8080
2021-12-17 12:24:49 INFO <> [io.quarkus.bootstrap.runner.Timing] (main) Profile prod activated. 
2021-12-17 12:24:49 INFO <> [io.quarkus.bootstrap.runner.Timing] (main) Installed features: [agroal, apicurio-registry-avro, cdi, jdbc-postgresql, kafka-client, micrometer, narayana-jta, oidc, resteasy, resteasy-jackson, scheduler, security, servlet, smallrye-context-propagation, smallrye-health, vertx]
2021-12-17 12:24:52 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) Checking to see if the DB is initialized.
2021-12-17 12:24:53 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) Database not initialized.
2021-12-17 12:24:53 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) Initializing the Apicurio Registry database.
2021-12-17 12:24:53 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) 	Database type: postgresql
2021-12-17 12:24:53 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) Checking to see if the DB is up-to-date.
2021-12-17 12:24:53 INFO <> [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] (executor-thread-1) Build's DB version is 6
2021-12-17 12:24:53 INFO <> [io.apicurio.registry.storage.impl.sql.SqlRegistryStorage] (executor-thread-1) Using SQL artifactStore.
2021-12-17 12:25:48 WARN <> [com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord] (executor-thread-2) ARJUNA016039: onePhaseCommit on < formatId=131077, gtrid_length=35, bqual_length=36, tx_uid=0:ffff0a9798a6:9d3d:61bc8191:14, node_name=quarkus, branch_uid=0:ffff0a9798a6:9d3d:61bc8191:16, subordinatenodename=null, eis_name=0 > (io.agroal.narayana.LocalXAResource@4bcb5f18) failed with exception XAException.XA_RBROLLBACK: javax.transaction.xa.XAException: Error trying to transactionCommit local transaction: ERREUR: l'instruction pr?par?e ? S_1 ? existe d?j?
	at io.agroal.narayana.LocalXAResource.xaException(LocalXAResource.java:140)
	at io.agroal.narayana.LocalXAResource.xaException(LocalXAResource.java:134)
	at io.agroal.narayana.LocalXAResource.commit(LocalXAResource.java:72)

The healthcheck responds correctly too :

$ curl http://localhost:8080/health
{
    "status": "UP",
    "checks": [
        {
            "name": "StorageLivenessCheck",
            "status": "UP"
        },
        {
            "name": "ResponseErrorLivenessCheck",
            "status": "UP",
            "data": {
                "errorCount": 0
            }
        },
        {
            "name": "PersistenceTimeoutReadinessCheck",
            "status": "UP",
            "data": {
                "errorCount": 0
            }
        },
        {
            "name": "PersistenceExceptionLivenessCheck",
            "status": "UP",
            "data": {
                "errorCount": 0
            }
        },
        {
            "name": "Database connections health check",
            "status": "UP"
        },
        {
            "name": "PersistenceSimpleReadinessCheck",
            "status": "UP"
        },
        {
            "name": "ResponseTimeoutReadinessCheck",
            "status": "UP",
            "data": {
                "errorCount": 0
            }
        }
    ]
}

Maybe I should add that the database version is 11.12 :

apicuriodb=> select version();
                                                     version
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.12 (Debian 11.12-0+deb10u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit

Is Postgres version 11.12 supported ? If it is the case, what could be causing the error ?

[EricWittmann]

Is that the extent of your log messages? No additional stack traces or log messages? If there is more to the log there might be something in there that would be helpful.

@Apicurio/developers Any thoughts?

[Bewi42]

Here are some more logs, from startup.
logs-from-apicurio-registry.log

[EricWittmann]

Thanks! So I guess I'm wondering what ERREUR: l'instruction pr?par?e ? S_1 ? existe d?j? might translate to...

[Bewi42]

It translates to : ERROR: prepared statement "S_1" already exists Le ven. 17 déc. 2021 à 19:29, Eric Wittmann ***@***.***> a écrit :

…

Thanks! So I guess I'm wondering what ERREUR: l'instruction pr?par?e ? S_1 ? existe d?j? might translate to... — Reply to this email directly, view it on GitHub <#2124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBMH5NNXRSVLGB3MSNFZVTURN6Q3ANCNFSM5KI3AOKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Bewi42]

Problem looks to be resolved by adding "prepareThreshold=0" to the connection URL.
I don't know about any side effects though.

[EricWittmann]

Thank you for reporting back, @Bewi42 - I've not been able to reproduce this problem using PG 11 locally. :(

[Bewi42]

Me neither. The issue may be caused by server configuration.

[carlesarnal]

This error might appear depending on the actual configuration/deployment of the server, so it's very likely related to your configuration. What you did using that configuration is to disable server-side prepared statements, so it may impact your performance a bit, since, AFAIR, we're using prepared statements where possible. If you agree, I think we can close this one.

[Bewi42]

OK I agree.