Re: Is it possible to add support for PostgreSQL-15 and newer versions in omnipitr?

From: hailong(dot)li <hailong(dot)li(at)qunar(dot)com>
To: <depesz(at)depesz(dot)com>, xuzhao(dot)zhao <xuzhao(dot)zhao(at)qunar(dot)com>
Cc: <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Is it possible to add support for PostgreSQL-15 and newer versions in omnipitr?
Date: 2023-12-11 13:02:45
Message-ID: 8b807ace-32a0-4406-8a5e-267598107aa8@qunar.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

HI,Dear depesz

OmniPITR is an very excellent software!

Our company has been using it for over ten years!Our company has a large
number of PG instances,so omnipitr is extremely important to us!

Since we are not familiar with Perl, it will be very difficult for us to
maintain omnipitr ourselves. But it should be relatively easy for you.

*Please help us one more time!*

*
*

Btw, pgbackrest only supports the default 8k blocksize of PG
instances,but our blocksize is 32k.😭

On 2023/12/5 22:48, hubert depesz lubaczewski wrote:
>
>
> On Tue, Dec 05, 2023 at 01:10:18PM +0800, xuzhao.zhao wrote:
>> Hi depesz,
>> We currently use omnipitr-backup-slave to backup our database for PG14 and
>> earlier versions. However, there have been changes to the backup process in
>> PG15 that have rendered omnipitr-backup-slave unable to function.
>> Changes are as follows:
>>
>> * Functions pg_start_backup()/pg_stop_backup() have been renamed to
>> pg_backup_start()/pg_backup_stop()
>> * Remove long-deprecated exclusive backup mode. The connection calling
>> pg_backup_start must be maintained until the end of the backup, or
>> the backup will be automatically aborted.
>>
>> Is it possible for the omnipitr-backup-slave tool to execute
>> pg_start_backup() and keep the session open until it can also execute
>> pg_stop_backup() after the tarball is created?
> Hi,
> that would take some not-trivial changes, and the code isn't really
> maintained. I don't think the company that I developed it for even
> exists anymore.
>
> These days I would recommend migrating to something different like
> pgbackrest, for example.
>
> Best regards,
>
> depesz
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-12-11 15:05:53 Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
Previous Message Dean Rasheed 2023-12-11 12:53:35 Re: BUG #18238: Cross-partitition MERGE/UPDATE with delete-preventing trigger leads to incorrect memory access