From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file |
Date: | 2022-03-08 22:12:53 |
Message-ID: | 20220308221253.GA169440@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 08, 2022 at 03:09:50PM -0600, David Steele wrote:
> On 3/8/22 14:01, Nathan Bossart wrote:
>> On Wed, Mar 02, 2022 at 02:23:51PM -0500, Chapman Flack wrote:
>> > I did not notice this earlier (sorry), but there seems to remain in
>> > backup.sgml a programlisting example that shows a psql invocation
>> > for pg_backup_start, then a tar command, then another psql invocation
>> > for pg_backup_stop.
>> >
>> > I think that was only workable for the exclusive mode, and now it is
>> > necessary to issue pg_backup_start and pg_backup_stop in the same session.
>> >
>> > (The 'touch backup_in_progress' business seems a bit bogus now too,
>> > suggesting an exclusivity remembered from bygone days.)
>> >
>> > I am not sure what a workable, simple example ought to look like.
>> > Maybe a single psql script issuing the pg_backup_start and the
>> > pg_backup_stop, with a tar command in between with \! ?
>> >
>> > Several bricks shy of production-ready, but it would give the idea.
>>
>> Another option might be to just remove this section. The top of the
>> section mentions that this is easily done using pg_basebackup with the -X
>> parameter. The bottom part of the section includes more complicated steps
>> for when "more flexibility in copying the backup files is needed..."
>> AFAICT the more complicated strategy was around before pg_basebackup, and
>> the pg_basebackup recommendation was added in 2012 as part of 920febd.
>> Thoughts?
>
> This makes sense to me. I think pg_basebackup is far preferable to doing
> anything like what is described in this section. Unless you are planning to
> do something fancy (parallelization, snapshots, object stores, etc.) then
> pg_basebackup is the way to go.
I spent some time trying to come up with a workable script to replace the
existing one. I think the main problem is that you need to write out both
the backup label file and the tablespace map file, but I didn't find an
easy way to write the different output columns of pg_backup_stop() to
separate files via psql. We'd probably need to write out the steps in
prose like the 'Making a Base Backup Using the Low Level API' section does.
Ultimately, I just removed everything beyond the pg_basebackup
recommendation in the 'Standalone Hot Backups' section.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
v5-0001-remove-exclusive-backup-mode.patch | text/x-diff | 86.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-03-08 22:44:40 | Re: logical decoding and replication of sequences |
Previous Message | Robert Haas | 2022-03-08 21:42:08 | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |