| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| Subject: | Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file |
| Date: | 2021-12-01 00:54:18 |
| Message-ID: | YabHupPdb5PT0YsN@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 30, 2021 at 05:58:15PM -0500, David Steele wrote:
> The main objections as I recall are that it is much harder for simple backup
> scripts and commercial backup integrations to hold a connection to postgres
> open and write the backup label separately into the backup.
I don't quite understand why this argument would not hold even today,
even if I'd like to think that more people are using pg_basebackup.
> I did figure out how to keep the safe part of exclusive backup (not having
> to maintain a connection) while removing the dangerous part (writing
> backup_label into PGDATA), but it was a substantial amount of work and I
> felt that it had little chance of being committed.
Which was, I guess, done by storing the backup_label contents within a
file different than backup_label, still maintained in the main data
folder to ensure that it gets included in the backup?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-12-01 01:09:14 | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? |
| Previous Message | Andy Fan | 2021-12-01 00:50:12 | Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd |