Postgresql Disable Extension
Fortun Bawa
1. To enable an extension, first, navigate to the PostgreSQL Extensions page of your PostgreSQL cluster. From the PostgreSQL Extensions page, click the Enable button. You will be redirected to the form to enable available extensions.
1. To disable an extension, first, navigate to the PostgreSQL Extensions page of your PostgreSQL cluster. From the PostgreSQL Extensions page, click the Disable button on the extension that you want to disable. You will be redirected to the form to disable that particular extension.
Quarkus uses Agroal and Vert.x to provide high-performance, scalable data source connection pooling for JDBC and reactive drivers.The quarkus-jdbc-* and quarkus-reactive-*-client extensions provide build time optimizations and integrate configured data sources with Quarkus features like security, health checks, and metrics.
Quarkus simplifies database configuration by offering the Dev Services feature, enabling zero-config database setup for testing or running in development (dev) mode.In dev mode, the suggested approach is to use DevServices and let Quarkus handle the database for you, whereas for production mode, you provide explicit database configuration details pointing to a database managed outside of Quarkus.
To use Dev Services, add the appropriate driver extension, such as jdbc-postgresql, for your desired database type to the pom.xml file.In dev mode, if you do not provide any explicit database connection details, Quarkus automatically handles the database setup and provides the wiring between the application and the database.
To use this feature, ensure a Docker or Podman container runtime is installed, depending on the database type. Certain databases, such as H2, operate in in-memory mode and do not require a container runtime.
To protect your database from overloading during load peaks, size the pool adequately to throttle the database load.The optimal pool size depends on many factors, such as the number of parallel application users or the nature of the workload.
You can use any JDBC driver in a Quarkus app in JVM mode as described in Using other databases.However, using a non-built-in database kind is unlikely to work when compiling your application to a native executable.
Until now, the configuration has been the same regardless of whether you are using a JDBC or a reactive driver.When you have defined the database kind and the credentials, the rest depends on what type of driver you are using.It is possible to use JDBC and a reactive driver simultaneously.
Using a built-in JDBC driver extension automatically includes the Agroal extension, which is the JDBC connection pool implementation applicable for custom and built-in JDBC drivers.However, for custom drivers, Agroal needs to be added explicitly.
If you need to connect to a database for which Quarkus does not provide an extension with the JDBC driver, you can use a custom driver instead.For example, if you are using the OpenTracing JDBC driver in your project.
Without an extension, the driver will work correctly in any Quarkus app running in JVM mode.However, the driver is unlikely to work when compiling your application to a native executable.If you plan to make a native executable, use the existing JDBC Quarkus extensions, or contribute one for your driver.
To protect your database from overloading during load peaks, size the pool adequately to throttle the database load.The proper size always depends on many factors, such as the number of parallel application users or the nature of the workload.
To deactivate a datasource at runtime, set quarkus.datasource[.optional name].active to false.Then Quarkus will not start the corresponding JDBC connection pool or reactive client on application startup.Any attempt to use the corresponding datasource at runtime will fail with a clear error message.
Setting quarkus.datasource."pg".active=true at runtimewill make only the PostgreSQL datasource available,and setting quarkus.datasource."oracle".active=true at runtimewill make only the Oracle datasource available.
Custom configuration profiles can help simplify such a setup.By appending the following profile-specific configuration to the one above,you can select a persistence unit/datasource at runtime simply bysetting quarkus.profile:quarkus.profile=prod,pg or quarkus.profile=prod,oracle.
By default, XA support on datasources is disabled,and thus a transaction may include at most one datasource.Attempting to access multiple non-XA datasources in the same transactionwould result in an exception similar to this:
If you do not need a rollback for one datasource to trigger a rollback for other datasources,consider splitting your code into multiple transactions.To that end, use QuarkusTransaction.requiringNew()/@Transactional(REQUIRES_NEW) (preferably)or UserTransaction (for more complex use cases).
As a last resort, and for compatibility with Quarkus 3.8 and earlier,you may allow unsafe transaction handling across multiple non-XA datasourcesby setting quarkus.transaction-manager.unsafe-multiple-last-resources to allow.
With this property set to allow, a transaction rollbackcould possibly be applied to only some of the non-XA datasources,with other non-XA datasources having already committed their changes,leaving your overall system in an inconsistent state.
We do not recommend using this configuration property,and we plan to remove it in the future,so you should plan fixing your application accordingly.If you think your use case of this feature is valid and this option should be kept around,open an issue in the Quarkus trackerexplaining why.
If you are using the quarkus-micrometer or quarkus-smallrye-metrics extension, quarkus-agroal can contribute some datasource-related metrics to the metric registry.This can be activated by setting the quarkus.datasource.metrics.enabled property to true.
For the exposed metrics to contain any actual values, a metric collection must be enabled internally by the Agroal mechanisms.By default, this metric collection mechanism is enabled for all datasources when a metrics extension is present, and metrics for the Agroal extension are enabled.
To disable metrics for a particular data source,set quarkus.datasource.jdbc.enable-metrics to false, or apply quarkus.datasource..jdbc.enable-metrics for a named datasource.This disables collecting the metrics and exposing them in the /q/metrics endpoint if the mechanism to collect them is disabled.
Conversely, setting quarkus.datasource.jdbc.enable-metrics to true, or quarkus.datasource..jdbc.enable-metrics for a named datasource explicitly enables metrics collection even if a metrics extension is not in use.This can be useful if you need to access the collected metrics programmatically.They are available after calling dataSource.getMetrics() on an injected AgroalDataSource instance.
When using Dev Services, the default datasource will always be created, but to specify a named datasource, you need to have at least one build time property so Quarkus can detect how to create the datasource.
The recommended approach is to use the real database you intend to use in production, especially when Dev Services provide a zero-config database for testing, and running tests against a container is relatively quick and produces expected results on an actual environment.However, it is also possible to use JVM-powered databases for scenarios when the ability to run simple integration tests is required.
Derby cannot be embedded into the application in native mode.However, the Quarkus Derby extension allows native compilation of the Derby JDBC client, supporting remote connections.
A high version will allow better performance and using more features(e.g. Hibernate ORM may generate more efficient SQL,avoid workarounds and take advantage of more database features),but if it is higher than the version of the database you want to connect to,it may lead to runtime exceptions(e.g. Hibernate ORM may generate invalid SQL that your database will reject).
Some extensions (like the Hibernate ORM extension)will try to check this version against the actual database version on startup,leading to a startup failure when the actual version is loweror simply a warning in case the database cannot be reached.
The map key corresponds to the host location; the map value is the container location. If the host location starts with "classpath:", the mapping loads the resource from the classpath with read-only permission.
This configuration property is set to true by default,so it is mostly useful to disable reuse,if you enabled it in testcontainers.propertiesbut only want to use it for some of your Quarkus applications or datasources.
This is a bean name (as in @Named) of a bean that implements CredentialsProvider. It is used to select the credentials provider bean when multiple exist. This is unnecessary when there is only one credentials provider available.
The initial size of the pool. Usually you will want to set the initial size to match at least the minimal size, but this is not enforced so to allow for architectures which prefer a lazy initialization of the connections on boot, while being able to sustain a minimal pool size after boot.
Require an active transaction when acquiring a connection. Recommended for production. WARNING: Some extensions acquire connections without holding a transaction for things like schema updates and schema validation. Setting this setting to STRICT may lead to failures in those cases.
If multiple values are set, this datasource will create a pool with a list of servers instead of a single server. The pool uses round-robin load balancing for server selection during connection establishment. Note that certain drivers might not accommodate multiple values in this context.
When #event-loop-size is set to a strictly positive value, the pool assigns as many event loops as specified, in a round-robin fashion. By default, the number of event loops configured or calculated by Quarkus is used. If #event-loop-size is set to zero or a negative value, the pool assigns the current event loop to the new connection.
4a15465005