Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sjXpO-001gK2-B8 for pgsql-announce@arkaria.postgresql.org; Thu, 29 Aug 2024 05:36:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sjXpM-00FALx-Gz for pgsql-announce@arkaria.postgresql.org; Thu, 29 Aug 2024 05:36:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sjXpL-00FAL1-AC for pgsql-announce@lists.postgresql.org; Thu, 29 Aug 2024 05:36:12 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sjXpG-001xkj-Vq for pgsql-announce@lists.postgresql.org; Thu, 29 Aug 2024 05:36:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:From:To:Subject: MIME-Version:Content-Type:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=i8yYtXzsNaCAU6f41toZGS+rZI3rR4McndZh1fcNCQk=; b=JRIU9LW8L82CTmn9z4epUgE8vn KSIQ9L/YNbwon0bbEALol/kWRBlYE94yDSg3DFJdSq1Km6dkN2ztMD/37tu8t3tBt9akF1r1tNZwu MER6plYTaYiSvQIMQ+xRBEUyVFTX5hnbNXeEigC4SBLTK60p7VASSwnKJgOrNjdP48awoqsHmxHut x4TUOft4eaap/2kiLXUiIGbH05BSexYWVS6pJH3U8bLP/y86qliPlmILsbDQvuzJ2CXYZ0XW3Ykqq TeUkG9KI5i690B+yiV+IROed2SVhYMTesr04ai01G5yyX4g9nNl61AQPPLG06DiDSt2mpN0XZ4tWk WmEtGt5A==; Received: from wrigleys.postgresql.org ([217.196.149.60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sjXpF-006X33-LD for pgsql-announce@lists.postgresql.org; Thu, 29 Aug 2024 05:36:06 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sjXpD-008hNe-37 for pgsql-announce@lists.postgresql.org; Thu, 29 Aug 2024 05:36:03 +0000 Content-Type: multipart/mixed; boundary="===============1828131005717138296==" MIME-Version: 1.0 Subject: Release Announcement Barman 3.11.1 and 3.11.0 To: PostgreSQL Announce From: EDB via PostgreSQL Announce Reply-To: david.wagoner@enterprisedb.com Date: Thu, 29 Aug 2024 05:35:27 +0000 Message-ID: <172490972736.862885.15299438097582700371@wrigleys.postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-pglister-tags: related X-pglister-tagsig: 61c1798d36c6b966a0787dadbeee52cebe4a78466c7610eb604d6a511ef0d2c1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --===============1828131005717138296== Content-Type: multipart/alternative; boundary="===============8013977560796254148==" MIME-Version: 1.0 --===============8013977560796254148== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable [EDB](https://www.enterprisedb.com) is pleased to announce the release of B= arman 3.11.1 and 3.11.0.=20 ## Highlights of this release: ###Version 3.11.1 - 22 August 2024 ### Bug fixes: * Fix failures in `` ` ``barman-cloud-backup-delete`` ` ``. This command wa= s failing when applying retention policies due to a bug introduced by th= e previous release. ###Version 3.11.0 - 22 August 2024 #### Features: * Add support for Postgres 17+ incremental backups. This major feature is composed of several small changes: * Add `` ` ``--incremental`` ` `` command-line option to `` ` ``barman= backup`` ` `` command. This is used to specify the parent backup when taking an incremental backup. The parent can be either a full backup or another incremental backup. * Add `` ` ``latest-full`` ` `` shortcut backup ID. Along with `` ` ``= latest`` ` ``, this can be used as a shortcut to select the parent backup for an incremental backup. Wh= ile `` ` ``latest`` ` `` takes the latest backup independently if it is ful= l or incremental, `` ` ``latest-full`` ` `` takes the latest full backup. * `` ` ``barman keep`` ` `` command can only be applied to full backup= s when `` ` ``backup_method =3D postgres`` ` ``. If a full backup has incremen= tal backups that depend on it, all of the incrementals are also kept by Barman. * When deleting a backup all the incremental backups depending on it, = if any, are also removed. * Retention policies do not take incremental backups into consideratio= n. As incremental backups cannot be recovered without having the complete cha= in of backups available up to the full backup, only full backups account for retention policies. * `` ` ``barman recover`` ` `` needs to combine the full backup with t= he chain of incremental backups when recovering. The new CLI option `` ` ``--local-staging-path= `` ` ``, and the corresponding `` ` ``local_staging_path`` ` `` configuration option, ar= e used to specify the path in the Barman host where the backups will be combined when rec= overing an incremental backup. * Changes to `` ` ``barman show-backup`` ` `` output: * Add the =E2=80=9CEstimated cluster size=E2=80=9D field. It's useful = to have an estimation of the data directory size of a cluster when restoring a backup. It=E2= =80=99s particularly useful when recovering compressed backups or incremental backups, situations where the size of the backup doesn=E2=80=99t reflec= t the size of the data directory in Postgres. In JSON format, this is stored as `` ` ``cluster_size`` ` ``. * Add the =E2=80=9CWAL summarizer=E2=80=9D field. This field shows if = `` ` ``summarize_wal`` ` `` was enabled in Postgres at the time the backup was taken. In JSON format, t= his is stored as `` ` ``server_information.summarize_wal`` ` ``. This field= is omitted for Postgres 16 and older. * Add =E2=80=9CData checksums=E2=80=9D field. This shows if `` ` ``dat= a_checkums`` ` `` was enabled in Postgres at the time the backup was taken. In JSON format, this is stor= ed as `` ` ``server_information.data_checksums`` ` ``. * Add the =E2=80=9CBackup method=E2=80=9D field. This shows the backup= method used for this backup. In JSON format, this is stored as `` ` ``base_backup_information.backup_method`` ` ``. * Rename the field =E2=80=9CDisk Usage=E2=80=9D as =E2=80=9CBackup Siz= e=E2=80=9D. The latter provides a more comprehensive name which represents the size of the backup in the Barman host. The JSON field under `` ` ``base_backup_information`` ` `` was al= so renamed from `` ` ``disk_usage`` ` `` to `` ` ``backup_size`` ` ``. * Add the =E2=80=9CWAL size=E2=80=9D field. This shows the size of the= WALs required by the backup. In JSON format, this is stored as `` ` ``base_backup_information.wal_size`` ` ``. * Refactor the field =E2=80=9CIncremental size=E2=80=9D. It is now nam= ed =E2=80=9CResources saving=E2=80=9D and it now shows an estimation of resources saved when taking increment= al backups with `` ` ``rsync`` ` `` or `` ` ``pg_basebackup`` ` ``. It com= pares the backup size with the estimated cluster size to estimate the amount of disk and network resources that were saved by taking an incremental backup. In JSON form= at, the field was renamed from `` ` ``incremental_size`` ` `` to `` ` ``res= ource_savings`` ` `` under `` ` ``base_backup_information`` ` ``. * Add the `` ` ``system_id`` ` `` field to the JSON document. This fie= ld contains the system identifier of Postgres. It was present in console format, but was missing in JSON format. * Add fields related with Postgres incremental backups: * =E2=80=9CBackup type=E2=80=9D: indicates if the Postgres backup is= full or incremental. In JSON format, this is stored as `` ` ``backup_type`` ` `` under `` ` `= `base_backup_information`` ` ``. * =E2=80=9CRoot backup=E2=80=9D: the ID of the full backup that is t= he root of a chain of one or more incremental backups. In JSON format, this is stored as `` ` ``catalog_information.root_backup_id`` ` ``. * =E2=80=9CParent backup=E2=80=9D: the ID of the full or incremental= backup from which this incremental backup was taken. In JSON format, this is stored as `` ` ``catalog_information.parent_backup_id`` ` ``. * =E2=80=9CChildren Backup(s)=E2=80=9D: the IDs of the incremental b= ackups that were taken with this backup as the parent. In JSON format, this is stored as `` ` ``catalog_information.children_backup_ids`` ` ``. * =E2=80=9CBackup chain size=E2=80=9D: the number of backups in the = chain from this incremental backup up to the root backup. In JSON format, this is stored as `` ` ``catalog_information.chain_size`` ` ``. * Changes to `` ` ``barman list-backup`` ` `` output: * It now includes the backup type in the JSON output, which can be eit= her `` ` ``rsync`` ` `` for backups taken with rsync, `` ` ``full`` ` `` or= `` ` ``incremental`` ` `` for backups taken with `` ` ``pg_basebackup`` ` ``, or `` ` ``snapshot`` ` `` for c= loud snapshots. When printing to the console the backup type is represented by the corresponding labe= ls `` ` ``R`` ` ``, `` ` ``F`` ` ``, `` ` ``I`` ` `` or `` ` ``S`` ` ``. * Remove tablespaces information from the output. That was bloating the output. Tablespaces information can still be found in the output of=20 `` ` ``barman show-backup`` ` ``. * Always set a timestamp with a time zone when configuring `` ` ``recovery_target_time`` ` `` through `` ` ``barman recover`` ` ``. = Previously, if no time zone was explicitly set through `` ` ``--target-time`` ` ``, Barman would conf= igure `` ` ``recovery_target_time`` ` `` without a time zone in Postgres. Witho= ut a time zone, Postgres would assume whatever is configured through `` ` ``timezone`` ` = `` GUC in Postgres. From now on Barman will issue a warning and configure `` ` ``recovery_target_time`` ` `` with the time zone of the Barman host = if no time zone is set by the user through `` ` ``--target-time`` ` `` option. * When recovering a backup with the =E2=80=9Cno get wal=E2=80=9D approach a= nd `` ` ``--target-lsn`` ` `` is set, copy only the WAL files required to reach the configured target. Previous= ly Barman would copy all the WAL files from its archive to Postgres. * When recovering a backup with the =E2=80=9Cno get wal=E2=80=9D approach a= nd `` ` ``--target-immediate`` ` `` is set, copy only the WAL files required to reach the consistent point. Previously Barman would copy all the WAL files from its archive to Postgr= es. * `` ` ``barman-wal-restore`` ` `` now moves WALs from the spool directory = to `` ` ``pg_wal`` ` `` instead of copying them. This can improve performance if the spool direct= ory and the `` ` ``pg_wal`` ` `` directory are in the same partition. * `` ` ``barman check-backup`` ` `` now shows the reason why a backup was m= arked as `` ` ``FAILED`` ` `` in the output and logs. Previously for a user to know why the backup was marked as `` ` ``FAILED`` ` ``, they would need to run `` ` ``barman show= -backup`` ` `` command. * Add configuration option `` ` ``aws_await_snapshots_timeout`` ` `` and th= e corresponding `` ` ``--aws-await-snapshots-timeout`` ` `` command-line option on `` ` `= `barman-cloud-backup`` ` ``. This specifies the timeout in seconds to wait for snapshot backups to rea= ch the completed state. * Add a keep-alive mechanism to rsync-based backups. Previously the Postgres session created by Barman to run `` ` ``pg_backup_start()`` ` `` and `` `= ``pg_backup_stop()`` ` `` would stay idle for as long as the base backup copy would take. That could lead= to a firewall or router dropping the connection because it was idle for a long time. The keep-alive mechanism sends heartbeat queries to Postgres through that connection, thus reducing the likelihood of a connection getting dropped. The interval between heartbeats can be controlled throug= h the new configuration option `` ` ``keepalive_interval`` ` `` and the correspondi= ng CLI option `` ` ``--keepalive-interval`` ` `` of the `` ` ``barman backup`` `= `` command. ### Bug fixes: * When recovering a backup with the =E2=80=9Cno get wal=E2=80=9D approach = and `` ` ``--target-time`` ` `` set, copy all WAL files. Previously Barman would attempt to =E2=80=9Cgu= ess=E2=80=9D the WAL files required by Postgres to reach the configured target time. However, the mechanism was not robust enough as it was based on the stats of the= WAL file in the Barman host (more specifically the creation time). For exam= ple: if there were archiving or streaming lag between Postgres and Barman, t= hat could be enough for recovery to fail because Barman would miss to copy = all the required WAL files due to the weak check based on file stats. * Pin `` ` ``python-snappy`` ` `` to `` ` ``0.6.1`` ` `` when running Barm= an through Python 3.6 or older. Newer versions of `` ` ``python-snappy`` ` `` require `` ` ``cramj= am`` ` `` version `` ` ``2.7.0`` ` `` or newer, and these are only available for Python 3.7 or newer. * `` ` ``barman receive-wal`` ` `` now exits with code `` ` ``1`` ` `` ins= tead of `` ` ``0`` ` `` in the following cases: * Being unable to run with `` ` ``--reset`` ` `` flag because `` ` ``p= g_receivewal`` ` `` is running. * Being unable to start `` ` ``pg_receivewal`` ` `` process because it= is already running. * Fix and improve information about Python in `` ` ``barman diagnose`` ` `= ` output: * The command now makes sure to use the same Python interpreter under = which Barman is installed when outputting the Python version through `` ` ``python_ver`` ` `` JSON key. Previously, if an environment had = multiple Python installations and/or virtual environments, the output could eventuall= y be misleading, as it could be fetched from a different Python interprete= r. * Added a `` ` ``python_executable`` ` `` key to the JSON output. That= contains the path to the exact Python interpreter being used by Barman. This information is also published in the [NEWS](https://github.com/Enterpr= iseDB/barman/blob/master/NEWS) for Barman. ### About Barman Backup and Recovery Manager (or Barman) is an open-source administration to= ol for remote backups and disaster recovery of PostgreSQL servers in busine= ss-critical environments. It relies on PostgreSQL's robust and reliable Poi= nt-In-Time Recovery technology, allowing DBAs to remotely manage a complete= catalog of backups and the recovery phase of multiple remote servers =E2= =80=93 all from one location. Barman is distributed under GNU GPL 3 and mai= ntained by [EDB](https://www.enterprisedb.com). --===============8013977560796254148== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Release Announcement Barman 3.11.1 and 3.11.0
 

Release Announcement Barman 3.11.1 and 3.11.0

EDB is pleased to an= nounce the release of Barman 3.11.1 and 3.11.0.

Highlights of this release:

Version 3.11.1 - 22 August 2024=

Bug fixes:

  • Fix failures in= `barman-cloud-backup-delete`. This command was f= ailing when applying retention policies due to a bug introduced by the p= revious release.

Version 3.11.0 - 22 August 2024=

Features:

  • Add support for Postgres 17+ incremental ba= ckups. This major feature is composed of several small changes:

    • Add `--incremental` command-line option to `barman backup` command= . This is used to specify the parent backup when taking an incremental backup. The parent can be either a full backup or another incremental backup.

    • Add `latest-full`= shortcut backup ID. Along with `latest`, this ca= n be used as a shortcut to select the parent backup for an incremental backup. While `latest` takes the latest backup independently if= it is full or incremental, `latest-full` takes the latest full backup.

    • `barman keep` com= mand can only be applied to full backups when `backup_method =3D postgres`. If a full backup ha= s incremental backups that depend on it, all of the incrementals are also kept by Barman.

    • When deleting a backup all the incremental = backups depending on it, if any, are also removed.

    • Retention policies do not take incremental = backups into consideration. As incremental backups cannot be recovered without having the complete chain of backups available up to the full backup, only full backups account for retention policies.

    • `barman recover` = needs to combine the full backup with the chain of incremental backups when recovering. The new CLI option `--local-staging-p= ath`, and the corresponding `local_staging_path` configuration = option, are used to specify the path in the Barman host where the backups will be combined when recover= ing an incremental backup.

  • Changes to `barman show-backup= ` output:

    • Add the =E2=80=9CEstimated cluster size=E2= =80=9D field. It's useful to have an estimation of the data directory size of a cluster when restoring a backup. It=E2=80= =99s particularly useful when recovering compressed backups or incremental backups, situations where the size of the backup doesn=E2=80=99t reflect th= e size of the data directory in Postgres. In JSON format, this is stored as `cluster_size`.

    • Add the =E2=80=9CWAL summarizer=E2=80=9D fi= eld. This field shows if `summarize_wal` was enabled in Postgres at the time the backup was taken. In JSON format, this is stored as `server_information.summarize_wal`. = This field is omitted for Postgres 16 and older.

    • Add =E2=80=9CData checksums=E2=80=9D field.= This shows if `data_checkums` was enabled in Postgres at the time the backup was taken. In JSON format, this is stored as `server_information.data_checksums`.

    • Add the =E2=80=9CBackup method=E2=80=9D fie= ld. This shows the backup method used for this backup. In JSON format, this is stored as `base_backup_information.backup_method`.

    • Rename the field =E2=80=9CDisk Usage=E2=80= =9D as =E2=80=9CBackup Size=E2=80=9D. The latter provides a more comprehensive name which represents the size of the backup in the Barman host. The JSON field under `base_backup_information` was also renamed from `disk_usage` to `backup_size`<= /code>.

    • Add the =E2=80=9CWAL size=E2=80=9D field. T= his shows the size of the WALs required by the backup. In JSON format, this is stored as `base_backup_information.wal_size`.

    • Refactor the field =E2=80=9CIncremental siz= e=E2=80=9D. It is now named =E2=80=9CResources saving=E2=80=9D and it now shows an estimation of resources saved when taking incremental backups with `rsync` or `pg_baseback= up`. It compares the backup size with the estimated cluster size to estimate the amount of disk and network resources that were saved by taking an incremental backup. In JSON format, the field was renamed from `incremental_size` to = `resource_savings` under `base_backu= p_information`.

    • Add the `system_id` field to the JSON document. This field contains the system identifier of Postgres. It was present in console format, but was missing in JSON format.

  • Add fields related with Postgres incrementa= l backups:

    • =E2=80=9CBackup type=E2=80=9D: indicates if= the Postgres backup is full or incremental. In JSON format, this is stored as `backup_type` un= der `base_backup_information`.

    • =E2=80=9CRoot backup=E2=80=9D: the ID of th= e full backup that is the root of a chain of one or more incremental backups. In JSON format, this is stored as `catalog_information.root_backup_id`.

    • =E2=80=9CParent backup=E2=80=9D: the ID of = the full or incremental backup from which this incremental backup was taken. In JSON format, this is stored as `catalog_information.parent_backup_id`.

    • =E2=80=9CChildren Backup(s)=E2=80=9D: the I= Ds of the incremental backups that were taken with this backup as the parent. In JSON format, this is stored as `catalog_information.children_backup_ids`.

    • =E2=80=9CBackup chain size=E2=80=9D: the nu= mber of backups in the chain from this incremental backup up to the root backup. In JSON format, this is stored as `catalog_information.chain_size`.

  • Changes to `barman list-backup= ` output:

    • It now includes the backup type in the JSON= output, which can be either `rsync` for backups taken with rsync, `full` or `incremental` for backups taken with `pg_basebackup`, or `snap= shot` for cloud snapshots. When printing to the console the backup type is represented by the corresponding labels `R`, `F`, `I` or `S`.

    • Remove tablespaces information from the out= put. That was bloating the output. Tablespaces information can still be found in the output of=20 `barman show-backup`.

  • Always set a timestamp with a time zone whe= n configuring `recovery_target_time` through `ba= rman recover`. Previously, if no time zone was explicitly set through `--target-time`, Bar= man would configure `recovery_target_time` without a time zone in P= ostgres. Without a time zone, Postgres would assume whatever is configured through `timezo= ne` GUC in Postgres. From now on Barman will issue a warning and configure `recovery_target_time` with the time zone of th= e Barman host if no time zone is set by the user through `--target-time` opti= on.

  • When recovering a backup with the =E2=80=9C= no get wal=E2=80=9D approach and `--target-lsn` i= s set, copy only the WAL files required to reach the configured target. Previous= ly Barman would copy all the WAL files from its archive to Postgres.

  • When recovering a backup with the =E2=80=9C= no get wal=E2=80=9D approach and `--target-immediate` is set, copy only the WAL files required to reach the consistent point. Previously Barman would copy all the WAL files from its archive to Postgr= es.

  • `barman-wal-restore` now moves WALs from the spool directory to `pg_wal`<= /code> instead of copying them. This can improve performance if the spool direct= ory and the `pg_wal` directory are in the same part= ition.

  • `barman check-backup` now shows the reason why a backup was marked as `FAILED` in the output and logs. Previously for a user to know why the backup was marked as `FAILED`, they would need to run `barman show-backup` command.

  • Add configuration option `aws_= await_snapshots_timeout` and the corresponding `--aws-await-snapshots-timeout` command-line op= tion on `barman-cloud-backup`. This specifies the timeout in seconds to wait for snapshot backups to rea= ch the completed state.

  • Add a keep-alive mechanism to rsync-based b= ackups. Previously the Postgres session created by Barman to run `pg_backup_start()` and `pg_backup_stop()` would stay idle for as long as the base backup copy would take. That could lead= to a firewall or router dropping the connection because it was idle for a long time. The keep-alive mechanism sends heartbeat queries to Postgres through that connection, thus reducing the likelihood of a connection getting dropped. The interval between heartbeats can be controlled throug= h the new configuration option `keepalive_interval` and t= he corresponding CLI option `--keepalive-interval` of the `barman backup` command.

Bug fixes:

  • When recovering a backup with the =E2=80=9C= no get wal=E2=80=9D approach and `--target-time` set, copy all WAL files. Previously Barman would attempt to =E2=80=9Cgu= ess=E2=80=9D the WAL files required by Postgres to reach the configured target time. However, the mechanism was not robust enough as it was based on the stats of the= WAL file in the Barman host (more specifically the creation time). For exam= ple: if there were archiving or streaming lag between Postgres and Barman, t= hat could be enough for recovery to fail because Barman would miss to copy = all the required WAL files due to the weak check based on file stats.

  • Pin `python-snappy` to `0.6.1` when running Barman through Python = 3.6 or older. Newer versions of `python-snappy` requir= e `cramjam` version `2.7.0` or newer, and these are only available for Python 3.7 or newer.

  • `barman receive-wal` now exits with code `1` instead of `0` in the following cases:

    • Being unable to run with `--re= set` flag because `pg_receivewal` is running.

    • Being unable to start `pg_rece= ivewal` process because it is already running.

  • Fix and improve information about Python in= `barman diagnose` output:

    • The command now makes sure to use the same = Python interpreter under which Barman is installed when outputting the Python version through `python_ver` JSON key. Previously, if an enviro= nment had multiple Python installations and/or virtual environments, the output could eventually be misleading, as it could be fetched from a different Python interpreter.

    • Added a `python_executable` key to the JSON output. That contains the path to the exact Python interpreter being used by Barman.

This information is also published in the <= a href=3D"https://github.com/EnterpriseDB/barman/blob/master/NEWS" style=3D= "color: #3498db; text-decoration: underline">NEWS for Barman.

About Barman

Backup and Recovery Manager (or Barman) is = an open-source administration tool for remote backups and disaster recovery= of PostgreSQL servers in business-critical environments. It relies on Post= greSQL's robust and reliable Point-In-Time Recovery technology, allowing DB= As to remotely manage a complete catalog of backups and the recovery phase = of multiple remote servers =E2=80=93 all from one location. Barman is distr= ibuted under GNU GPL 3 and maintained by EDB.
This email was sent to you from EDB. It was delivered on their behalf by the PostgreSQL project. Any questions about the content of the message shou= ld be sent to EDB.

You were sent this email as a subscriber of the pgsql-announce mai= linglist, for the content tag Related Open Source. To unsubscribe from further emails, or change which emails you want to receive, please click th= e personal unsubscribe link that you can find in the headers of this email, or visit https://lists.postgresql.org/unsubscribe/.
 
--===============8013977560796254148==-- --===============1828131005717138296==--