From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Christophe Pettus <xof(at)thebuild(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove Deprecated Exclusive Backup Mode |
Date: | 2019-02-25 06:29:44 |
Message-ID: | 079b6237-4ecc-0273-41e9-9ac49cb75cac@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/24/19 11:36 PM, Stephen Frost wrote:
> Greetings,
>
> * Laurenz Albe (laurenz(dot)albe(at)cybertec(dot)at) wrote:
>> Stephen Frost wrote:
>>> Yes, it *is* impossible to do safe backups with the existing API. There
>>> is an unquestionable race condition where a system restart will cause
>>> your system to not come back up without you going in and removing the
>>> backup_label file- and the only way you make that race window small is
>>> to remove the backup_label file right after you run pg_start_backup and
>>> copy it, and then PUT IT BACK at the end before you call pg_stop_backup,
>>> which is insane, but otherwise the 'race window' is the ENTIRE length of
>>> the backup.
>>
>> I just have an idea:
>>
>> What about an option to keep WAL around for the duration of an exclusive backup?
>>
>> That way PostgreSQL can still restart after a crash. It will take longer than
>> expected, but it will work. But then, perhaps the long recovery time is only
>> marginally better than having to manually delete the backup_label file...
>
> I'm afraid that we'd end up with many, many complaints about people
> running out of disk space on WAL when they are trying to take a backup..
This would also require replaying all that WAL during crash recovery
which could mean a much longer startup time.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | 이재훈 | 2019-02-25 06:36:58 | ERROR: could not read block 0 in file "global/XXXXX": Bad address Problem |
Previous Message | Kyotaro HORIGUCHI | 2019-02-25 06:26:53 | Re: Protect syscache from bloating with negative cache entries |