diff --git a/product_docs/docs/biganimal/release/using_cluster/01_postgres_access.mdx b/product_docs/docs/biganimal/release/using_cluster/01_postgres_access.mdx index 58a0ade57b5..695de8d50d6 100644 --- a/product_docs/docs/biganimal/release/using_cluster/01_postgres_access.mdx +++ b/product_docs/docs/biganimal/release/using_cluster/01_postgres_access.mdx @@ -7,7 +7,7 @@ You control access to your Postgres database by database authentication implemen For information on portal authentication, see: - [Setting up your identity provider](/biganimal/latest/getting_started/identity_provider/) if you purchased BigAnimal directly from EDB, or -- [Setting up your Azure Marketplace account](biganimal/latest/getting_started/02_azure_market_setup/) if you purchased BigAnimal through Azure Marketplace +- [Setting up your Azure Marketplace account](/biganimal/latest/getting_started/02_azure_market_setup/) if you purchased BigAnimal through Azure Marketplace ## Setting up your database authentication Don't use the `edb_admin` database role and `edb_admin` database created when creating your cluster in your application. Instead, create a new database role and a new database, which provides a high level of isolation in Postgres. If multiple applications are using the same cluster, each database can also contain multiple schemas, essentially a namespace in the database. If strict isolation is needed, use a dedicated cluster or dedicated database. If that strict isolation level isn't required, you can deploy a single database with multiple schemas. Refer to [Privileges](https://www.postgresql.org/docs/current/ddl-priv.html) in the PostgreSQL documentation to further customize ownership and roles to your requirements. diff --git a/product_docs/docs/biganimal/release/using_cluster/02_connecting_your_cluster/01_connecting_from_azure/index.mdx b/product_docs/docs/biganimal/release/using_cluster/02_connecting_your_cluster/01_connecting_from_azure/index.mdx index 7ae1acbff26..f94ffca1f0d 100644 --- a/product_docs/docs/biganimal/release/using_cluster/02_connecting_your_cluster/01_connecting_from_azure/index.mdx +++ b/product_docs/docs/biganimal/release/using_cluster/02_connecting_your_cluster/01_connecting_from_azure/index.mdx @@ -68,7 +68,7 @@ In this example, you create an Azure Private Endpoint in your client VM's virtua ### Step 1: Create an Azure Private Endpoint -Create an Azure Private Endpoint in each client virtual network that needs to connect to your BigAnimal cluster. You can create the Private Endpoint either using the [Azure portal](using-the-azure-portal) or the [Azure CLI](#using-the-azure-cli). +Create an Azure Private Endpoint in each client virtual network that needs to connect to your BigAnimal cluster. You can create the Private Endpoint either using the [Azure portal](#using-the-azure-portal) or the [Azure CLI](#using-the-azure-cli). #### Using the Azure Portal @@ -126,7 +126,7 @@ you created by entering the following details: 9. Select **Create**. -10. Proceed to [Accessing the cluster](accessing-the-cluster). +10. Proceed to [Accessing the cluster](#accessing-the-cluster). #### Using the Azure CLI diff --git a/product_docs/docs/efm/4/efm_deploy_arch/06_efm_pgpool.mdx b/product_docs/docs/efm/4/efm_deploy_arch/06_efm_pgpool.mdx index 540ffb46a37..fb7f74a3675 100644 --- a/product_docs/docs/efm/4/efm_deploy_arch/06_efm_pgpool.mdx +++ b/product_docs/docs/efm/4/efm_deploy_arch/06_efm_pgpool.mdx @@ -251,9 +251,10 @@ Add the following rules to the security groups to be used by the EDB Pgpool-II i #### Configuring NLB in Azure -If using AWS, see [Configuring NLB in AWS](#config_nlb_aws). +If using AWS, see [Configuring NLB in AWS](#configuring-nlb-in-aws). -After configuring the rules described in [Creating rules for security groups](#sg_rules_pgpool), follow the Azure +After configuring the security group rules described in [Configuring the network load balancer +](#configuring-the-network-load-balancer), follow the Azure documentation to: - Create a backend pool consisting of all the virtual machines running EDB Pgpool-II instances. Use the private IPs of the virtual machines to create the backend pool. @@ -284,7 +285,8 @@ The following assumptions have been taken for the sample configuration: - There is a security group for EDB Pgpool-II and a security group for the database instances. -After configuring the rules described in [Creating rules for security groups](#sg_rules_pgpool), follow the AWS documentation to: +After configuring the security group rules described in [Configuring the network load balancer +](#configuring-the-network-load-balancer), follow the AWS documentation to: - Create two target groups with the following details: diff --git a/product_docs/docs/epas/15/epas_compat_spl/10_collections/02_nested_tables.mdx b/product_docs/docs/epas/15/epas_compat_spl/10_collections/02_nested_tables.mdx index e95d9ca9e32..c09489ab619 100644 --- a/product_docs/docs/epas/15/epas_compat_spl/10_collections/02_nested_tables.mdx +++ b/product_docs/docs/epas/15/epas_compat_spl/10_collections/02_nested_tables.mdx @@ -30,7 +30,7 @@ Where: `objtype` is a previously defined object type. !!! Note - You can use the `CREATE TYPE` command to define a nested table type that's available to all SPL programs in the database. See [Database Compatibility for Oracle Developers: SQL](/epas_compat_sql) for more information about the `CREATE TYPE` command. + You can use the `CREATE TYPE` command to define a nested table type that's available to all SPL programs in the database. See [Database Compatibility for Oracle Developers: SQL](../../epas_compat_sql/39_create_type/) for more information about the `CREATE TYPE` command. To use the table, you must declare a *variable* of that nested table type. The following is the syntax for declaring a table variable: diff --git a/product_docs/docs/epas/15/epas_security_guide/02_protecting_against_sql_injection_attacks/01_sql_protect_overview.mdx b/product_docs/docs/epas/15/epas_security_guide/02_protecting_against_sql_injection_attacks/01_sql_protect_overview.mdx index 7bd4b0fdccc..e957a15280f 100644 --- a/product_docs/docs/epas/15/epas_security_guide/02_protecting_against_sql_injection_attacks/01_sql_protect_overview.mdx +++ b/product_docs/docs/epas/15/epas_security_guide/02_protecting_against_sql_injection_attacks/01_sql_protect_overview.mdx @@ -62,7 +62,7 @@ Either alter a protected role that has the superuser privilege so that it's no l ### Attack attempt statistics -SQL/Protect records each use of a command by a protected role that's considered an attack. It collects statistics by type of SQL injection attack, as discussed in [Types of SQL injection attacks](#types-of-injection-attacks). +SQL/Protect records each use of a command by a protected role that's considered an attack. It collects statistics by type of SQL injection attack, as discussed in [Types of SQL injection attacks](../02_protecting_against_sql_injection_attacks/01_sql_protect_overview/#types-of-sql-injection-attacks). You can access these statistics from the view `edb_sql_protect_stats`. You can easily monitor this view to identify the start of a potential attack. diff --git a/product_docs/docs/epas/15/installing/linux_install_details/managing_an_advanced_server_installation.mdx b/product_docs/docs/epas/15/installing/linux_install_details/managing_an_advanced_server_installation.mdx index e9eabddc83b..70ee759db39 100644 --- a/product_docs/docs/epas/15/installing/linux_install_details/managing_an_advanced_server_installation.mdx +++ b/product_docs/docs/epas/15/installing/linux_install_details/managing_an_advanced_server_installation.mdx @@ -290,7 +290,7 @@ Include the `--redwood-like` keywords to use an escape character, that is, an em `--icu-short-form` -Include the `--icu-short-form` keywords to create a cluster that uses a default International Components for Unicode (ICU) collation for all databases in the cluster. For more information about Unicode collations, see [Unicode collation algorithm](epas/latest/epas_guide/03_database_administration/06_unicode_collation_algorithm/). +Include the `--icu-short-form` keywords to create a cluster that uses a default International Components for Unicode (ICU) collation for all databases in the cluster. For more information about Unicode collations, see [Unicode collation algorithm](../../epas_guide/03_database_administration/06_unicode_collation_algorithm/). For more information about using `initdb` and the available cluster configuration options, see the [PostgreSQL core documentation](https://www.postgresql.org/docs/current/static/app-initdb.html). diff --git a/product_docs/docs/pem/9/certificates/index.mdx b/product_docs/docs/pem/9/certificates/index.mdx index 67189cc8622..1d418884bf1 100644 --- a/product_docs/docs/pem/9/certificates/index.mdx +++ b/product_docs/docs/pem/9/certificates/index.mdx @@ -45,7 +45,7 @@ To increase security, you can replace the httpd self-signed SSL certificates wit By default, PEM implements secured SSL/TLS connections between PEM agents and the backend database. It also acts as its own certificate authority (CA) to generate certificates and keys for the PEM server and agent. The self-signed SSL certificates and keys for the PEM server and agent are generated during PEM installation. These certificates and keys encrypt the connection from agent to server. In addition, PEM agents are authenticated using their certificate rather than a password. -You can replace the PEM self-signed SSL certificates and keys with the trusted CA certificates and keys. For more information, see [Trusted CA certificates and keys](/pem/latest/certificates/#use-certificates-and-keys-signed-by-trusted-CA). +You can replace the PEM self-signed SSL certificates and keys with the trusted CA certificates and keys. For more information, see [Trusted CA certificates and keys](#use-certificates-and-keys-signed-by-trusted-ca). ### How PEM self-signed SSL certificates work diff --git a/product_docs/docs/pem/9/considerations/pem_security_best_practices/pem_application_configuration.mdx b/product_docs/docs/pem/9/considerations/pem_security_best_practices/pem_application_configuration.mdx index b63b1993449..46d1a73e25d 100644 --- a/product_docs/docs/pem/9/considerations/pem_security_best_practices/pem_application_configuration.mdx +++ b/product_docs/docs/pem/9/considerations/pem_security_best_practices/pem_application_configuration.mdx @@ -120,7 +120,7 @@ HKEY_LOCAL_MACHINE\Software\Wow6432Node\EnterpriseDB\PEM\agent\ ## Changing the pemAgent and PEM backend database server certificates -By default, when you install PEM, the installer generates and uses self-signed certificates for the pemAgent and PEM database server. PemAgent uses these certificates when connecting to the PEM database server. To use your own SSL certificate for the pemAgent and PEM database server, see [Managing certificates](/pem/latest/managing_certificates/). +By default, when you install PEM, the installer generates and uses self-signed certificates for the pemAgent and PEM database server. PemAgent uses these certificates when connecting to the PEM database server. To use your own SSL certificate for the pemAgent and PEM database server, see [Managing certificates](../../certificates/). !!! Note PEM doesn't support placing the SSL CA certificates at a custom location. Don't change the location of `ca_certificate.crt` and `ca_key.key`. diff --git a/product_docs/docs/pem/9/pem_architecture.mdx b/product_docs/docs/pem/9/pem_architecture.mdx index f8a361a3bca..ba9ca3f6d67 100644 --- a/product_docs/docs/pem/9/pem_architecture.mdx +++ b/product_docs/docs/pem/9/pem_architecture.mdx @@ -15,7 +15,7 @@ redirects: Postgres Enterprise Manager (PEM) monitors and manages multiple Postgres servers through a single graphical interface. PEM can monitor the following areas of the infrastructure: - **Hosts** — One or more servers (physical or virtual) and their operating systems. -- **Database servers** — One or more instances of PostgreSQL or EDB Postgres Advanced Server or EDB Postgres Extended Server (formerly known as 2ndQPostgres) running on a host. +- **Database servers** — One or more instances of PostgreSQL, EDB Postgres Advanced Server, or EDB Postgres Extended Server (formerly known as 2ndQPostgres) running on a host. - **Databases** — One or more databases and their schema objects, such as tables and indexes. !!! Note @@ -26,7 +26,7 @@ PEM consists of individual software components: - **PEM server** — The PEM server is the data repository for monitoring data and a server to which agents and clients connect. The PEM server consists of an instance of PostgreSQL, an associated database for storing monitoring data, and a server that provides web services. - **PEM agent** — The PEM agent is responsible for executing tasks and reporting statistics from the agent host and the monitored Postgres instances to the PEM server. A single PEM agent can monitor multiple installed instances of Postgres that reside on the same host where the agent is installed or on multiple remote hosts. You can install an agent as part of the PEM server installation or you can install a stand-alone agent. - **PEM web client** — The PEM web interface allows you to manage and monitor Postgres servers and use PEM extended functionality. The web interface software is installed with the PEM server and is accessed using any supported web browser. -- **SQL Profiler** — SQL Profiler is a Postgres server plugin to record the monitoring data and query plans for the SQL Profiler tool to analyze in PEM. This is an optional component of PEM, but the plugin must be installed in each instance of Postgres for which you want to use it. You can use the SQL Profiler with any supported version of an EDB distribution of a PostgreSQL server or EDB Postgres Advanced Server, not just those managed through the PEM server. See [SQL Profiler Configuration](/pem/latest/profiling_workloads/pem_sqlprofiler/) for details and supported versions. +- **SQL Profiler** — SQL Profiler is a Postgres server extension to record the monitoring data and query plans for the SQL Profiler tool to analyze in PEM. This is an optional component of PEM, but the extension must be enabled in each instance of Postgres for which you want to use it. You can use the SQL Profiler with any supported version of an EDB distribution of Postgres, not just those managed through the PEM server. See [Installing SQL Profiler](profiling_workloads/installing_sql_profiler/) for details and supported versions. ## PEM architecture @@ -42,8 +42,8 @@ The PEM server consists of an instance of Postgres, an instance of the Apache we The instance of Postgres (a database server) and an instance of the Apache web-server HTTPD) can be on the same host or on separate hosts. - !!! Note - All the PEM features are available on either backend database server you select: PostgreSQL or EDB Postgres Advanced Server. +!!! Note + All the PEM features are available on either backend database server you select: PostgreSQL or EDB Postgres Advanced Server. - **Postgres instance (database server)** — This is the backend database server. It hosts a database named `pem`, which acts as the repository for PEM server. The `pem` database contains several schemas that store metric data collected from each monitored host, server, and database. @@ -101,12 +101,10 @@ The PEM client is a web-based application that runs in supported browsers. The c The client allows you to use PEM functionality that makes use of the data logged on the server through features such as dashboards, the Postgres Log Analysis Expert, and Capacity Manager. -### SQL Profiler plugin - -You don't have to install the SQL Profiler plugin on every server, but you must install and configure the plugin on each server on which you want to use the SQL Profiler. You might also want to install and configure SQL Profiler on unmonitored development servers. You can also temporarily install the SQL Profiler plugin for ad hoc use. +### SQL Profiler extension -The plugin is installed with the EDB Postgres Advanced Server distribution but must be installed separately for use with PostgreSQL. The SQL Profiler installer is available from the [EDB website](https://www.enterprisedb.com/downloads/edb-postgres-enterprise-manager). +You don't have to install the SQL Profiler extension on every server, but you must install and enable the extension on each server on which you want to use SQL Profiler. You might also want to install and enable the SQL Profiler extension on unmonitored development servers. You can also temporarily install the SQL Profiler extension for ad hoc use. -You can use SQL Profiler on servers that aren't managed through PEM. However, to perform scheduled traces, a server must have the plugin installed and must be managed by an installed and configured PEM agent. +You can use SQL Profiler on servers that aren't managed through PEM. However, to perform scheduled traces, a server must have the extension installed and enabled and must be managed by an installed and configured PEM agent. -For more information about using SQL Profiler, see [SQL Profiler](/pem/latest/profiling_workloads/pem_sqlprofiler/). +For more information, see [Installing SQL Provider](profiling_workloads/installing_sql_profiler/) and [Using SQL Profiler](profiling_workloads/using_sql_profiler/). diff --git a/product_docs/docs/pem/9/registering_agent.mdx b/product_docs/docs/pem/9/registering_agent.mdx index b5b0154a568..d60e43f8739 100644 --- a/product_docs/docs/pem/9/registering_agent.mdx +++ b/product_docs/docs/pem/9/registering_agent.mdx @@ -152,30 +152,31 @@ To use a nonroot user account to register a PEM agent, you must first install th 1. Log in as edb. Create `pem` and `logs` directories and assign read, write, and execute permissions: ```shell - $ mkdir /home/edb/pem - $ mkdir /home/edb/pem/logs - $ chmod 700 /home/edb/pem - $ chmod 700 /home/edb/pem/logs + # Running as nonroot user edb + mkdir /home/edb/pem + mkdir /home/edb/pem/logs + chmod 700 /home/edb/pem + chmod 700 /home/edb/pem/logs ``` 2. Register the agent with PEM server: ```shell - $ export PEM_SERVER_PASSWORD=edb + export PEM_SERVER_PASSWORD=edb # Use the following command to create agent certificates and an agent # configuration file (`agent.cfg`) in the `/home/edb/pem` directory. - $ /usr/edb/pem/agent/bin/pemworker --register-agent --pem-server <172.19.11.230> --pem-user postgres --pem-port 5432 --display-name non_root_pem_agent --cert-path /home/edb/pem --config-dir /home/edb/pem + /usr/edb/pem/agent/bin/pemworker --register-agent --pem-server <172.19.11.230> --pem-user postgres --pem-port 5432 --display-name non_root_pem_agent --cert-path /home/edb/pem --config-dir /home/edb/pem # Use the following command to assign read and write permissions to # these files: - $ chmod -R 600 /home/edb/pem/agent* + chmod -R 600 /home/edb/pem/agent* ``` 3. Change the parameters of the `agent.cfg` file: ```ini - $ vi /home/edb/pem/agent.cfg + vi /home/edb/pem/agent.cfg agent_ssl_key=/home/edb/pem/agent.key agent_ssl_crt=/home/edb/pem/agent.crt log_location=/home/edb/pem/worker.log @@ -187,16 +188,16 @@ To use a nonroot user account to register a PEM agent, you must first install th 4. Create a `tmp` directory, set the environment variable, and start the agent: ```ini - $ mkdir /home/edb/pem/tmp + mkdir /home/edb/pem/tmp # Create a script file, add the environment variable, give permissions, and execute: - $ vi /home/edb/pem/run_pemagent.sh + vi /home/edb/pem/run_pemagent.sh #!/bin/bash export TEMP=/home/edb/agent/tmp /usr/edb/pem/agent/bin/pemagent -c /home/edb/agent/agent.cfg - $ chmod a+x /home/edb/pem/run_pemagent.sh - $ cd /home/edb/pem - $ ./run_pemagent.sh + chmod a+x /home/edb/pem/run_pemagent.sh + cd /home/edb/pem + ./run_pemagent.sh ``` Your PEM agent is now registered and started with the edb user. If your machine restarts, then this agent doesn't restart automatically. You need to start it manually using the previous command. @@ -206,7 +207,7 @@ To use a nonroot user account to register a PEM agent, you must first install th a. Update the values for the configuration file path and the user in the `pemagent` service file as superuser: ```ini - $ sudo vi /usr/lib/systemd/system/pemagent.service + sudo vi /usr/lib/systemd/system/pemagent.service [Service] Type=forking WorkingDirectory=/home/edb/pem @@ -219,17 +220,19 @@ To use a nonroot user account to register a PEM agent, you must first install th ```shell # Find the process id of the running pem agent and pem worker process and kill that process - $ ps -ax | grep pemagent - $ kill -9 - $ ps -ax | grep pemworker - $ kill -9 + ps -ax | grep pemagent + kill -9 + ps -ax | grep pemworker + kill -9 # Enable and start pemagent service - $ sudo systemctl enable pemagent - $ sudo systemctl start pemagent - $ sudo systemctl status pemagent + sudo systemctl enable pemagent + sudo systemctl start pemagent + sudo systemctl status pemagent ``` 6. Check the agent status on the PEM dashboard. + !!! Note - Any probes and jobs that require root permission or access to a file owned by another user (for example, enterprisedb) fail. + - Any probes and jobs that require root permission or access to a file owned by another user (for example, enterprisedb) fail. + - If you move the `agent.cfg` file from its default location to another, the PEM dashboard might display the agent status as “unknown”. See [Troubleshooting agent issues](troubleshooting_agent/#updating-configuration-file-path-agent-status-displaying-as-unknown), for more information. diff --git a/product_docs/docs/pem/9/troubleshooting.mdx b/product_docs/docs/pem/9/troubleshooting.mdx index de46d213361..6dc580f9f73 100644 --- a/product_docs/docs/pem/9/troubleshooting.mdx +++ b/product_docs/docs/pem/9/troubleshooting.mdx @@ -88,3 +88,4 @@ In some situations, you might need to uninstall the PEM server, reinstall it, an ```shell /usr/edb/pem/bin/configure-pem-server.sh ``` + diff --git a/product_docs/docs/pem/9/troubleshooting_agent.mdx b/product_docs/docs/pem/9/troubleshooting_agent.mdx index 239b3540c03..d53fc230912 100644 --- a/product_docs/docs/pem/9/troubleshooting_agent.mdx +++ b/product_docs/docs/pem/9/troubleshooting_agent.mdx @@ -31,25 +31,55 @@ If an agent was deleted from the PEM web client but still has an entry in the `p The deleted agent is restored. However, the servers that were bound to that agent might appear to be down. To resolve this issue, modify the PEM agent properties of the server to add the bound agent again. After the successful modification, the servers appear as running properly. -## Using the command line to delete a PEM agent with down or unknown status -Using the PEM web interface to delete PEM agents with Down or Unknown status can be difficult if the number of such agents is large. In this situation, you can use the command line interface to delete Down or Unknown agents. +## Updating configuration file path (agent status displaying as unknown) -Use the following query to delete the agents that are Down for more than *N* number of hours: +If you move the agent configuration file (`agent.cfg`) from its default location `/usr/edb/pem/agent/etc` to another location, the PEM dashboard might display the agent status as “unknown”. In that case, you need to update the value of the agent configuration file path in the `pemagent` service file. +1. Use the following command to modify the `pemagent` service file as a superuser: + + ```shell + # Running as superuser + sudo vi /usr/lib/systemd/system/pemagent.service ``` - UPDATE pem.agent SET active=false WHERE id IN - (SELECT a.id FROM pem.agent - a JOIN pem.agent_heartbeat b ON (b.agent_id=a.id) - WHERE a.id IN - (SELECT agent_id FROM pem.agent_heartbeat WHERE (EXTRACT (HOUR FROM now())- - EXTRACT (HOUR FROM last_heartbeat)) > )); + +2. Update the `agent.cfg` file path. For example, on a Redhat host, update the file path: + + ```shell + ExecStart=/usr/edb/pem/agent/bin/pemagent -c /usr/edb/pem/agent/etc/agent.cfg ``` -Use the following query to delete the agents with an Unknown status: +3. Reload `systemd`, to update the modified service script: + ```shell + sudo systemctl daemon-reload ``` - UPDATE pem.agent SET active=false WHERE id IN - (SELECT id FROM pem.agent WHERE id NOT IN - (SELECT agent_id FROM pem.agent_heartbeat)); + +4. Restart the PEM agent: + + ```shell + sudo systemctl restart pemagent ``` + +## Using the command line to delete a PEM agent with down or unknown status + +Using the PEM web interface to delete PEM agents with Down or Unknown status can be difficult if the number of such agents is large. In this situation, you can use the command line interface to delete Down or Unknown agents. + +Use the following query to delete the agents that are Down for more than *N* number of hours: + +```sql +UPDATE pem.agent SET active=false WHERE id IN +(SELECT a.id FROM pem.agent +a JOIN pem.agent_heartbeat b ON (b.agent_id=a.id) +WHERE a.id IN +(SELECT agent_id FROM pem.agent_heartbeat WHERE (EXTRACT (HOUR FROM now())- +EXTRACT (HOUR FROM last_heartbeat)) > )); +``` + +Use the following query to delete the agents with an Unknown status: + +```sql +UPDATE pem.agent SET active=false WHERE id IN +(SELECT id FROM pem.agent WHERE id NOT IN +(SELECT agent_id FROM pem.agent_heartbeat)); +``` \ No newline at end of file diff --git a/product_docs/docs/pgd/5/rel_notes/index.mdx b/product_docs/docs/pgd/5/rel_notes/index.mdx index 405ffec39c3..3483b66bf93 100644 --- a/product_docs/docs/pgd/5/rel_notes/index.mdx +++ b/product_docs/docs/pgd/5/rel_notes/index.mdx @@ -2,7 +2,9 @@ title: "EDB Postgres Distributed Release notes" navTitle: "Release notes" navigation: +- pgd_5.0.1_rel_notes - pgd_5.0.0_rel_notes + --- The EDB Postgres Distributed documentation describes the latest version of EDB @@ -11,6 +13,8 @@ provide information on what was new in each release. For new functionality introduced in a minor or patch release, the content also indicates the release that introduced the feature. -| Release Date | EDB Postgres Distributed | BDR | -| ------------ | ---------------------------- | ----- | -| 2023 Feb 21 | [5.0.0](pgd_5.0.0_rel_notes) | 5.0.0 | +| Release Date | EDB Postgres Distributed | BDR extension | PGD CLI | PGD Proxy | +| ------------- | ---------------------------- | ------------- | ------- | --------- | +| 2023 Mar 21 | [5.0.1](pgd_5.0.1_rel_notes) | 5.0.0 | 5.0.1 | 5.0.1 | +| 2023 Feb 21 | [5.0.0](pgd_5.0.0_rel_notes) | 5.0.0 | 5.0.0 | 5.0.0 | + diff --git a/product_docs/docs/pgd/5/rel_notes/pgd_5.0.1_rel_notes.mdx b/product_docs/docs/pgd/5/rel_notes/pgd_5.0.1_rel_notes.mdx new file mode 100644 index 00000000000..0efb6351c7d --- /dev/null +++ b/product_docs/docs/pgd/5/rel_notes/pgd_5.0.1_rel_notes.mdx @@ -0,0 +1,12 @@ +--- +title: "Release notes for EDB Postgres Distributed version 5.0.1" +navTitle: "Version 5.0.1" +--- + +EDB Postgres Distributed version 5.0.1 is a patch version of EDB Postgres Distributed. +This version addresses security vulnerabilities in dependencies for PGD-Proxy and PGD-CLI. + +| Component | Version | Type | Description | +|-----------|---------|---------|------------------------------------------------------| +| CLI | 5.0.1 | Change | Upgrade dependencies to fix security vulnerabilities | +| Proxy | 5.0.1 | Change | Upgrade dependencies to fix security vulnerabilities | diff --git a/src/styles/_dark.scss b/src/styles/_dark.scss index 4b65d2392ce..a73eec929bc 100644 --- a/src/styles/_dark.scss +++ b/src/styles/_dark.scss @@ -153,11 +153,11 @@ html.dark { background-color: darken(#ffd8cc, 70%) !important; color: darken($light, 10%) !important; } - .admonition-tip { + .admonition-tip, .admonition-hint { background-color: darken(#e7f1db, 70%) !important; color: darken($light, 10%) !important; } - .admonition-note { + .admonition-note, .admonition-seealso { background-color: darken(#e4eef5, 70%) !important; color: darken($light, 10%) !important; } @@ -175,7 +175,7 @@ html.dark { } .admonition-heading h5:before { - content: url('data:image/svg+xml;utf8,'); + filter: invert(1); } }