From: | Peter <pmc(at)citylink(dot)dinoex(dot)sub(dot)org> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Something else about Redo Logs disappearing |
Date: | 2020-06-13 03:24:53 |
Message-ID: | 20200613032453.GA8494@gate.oper.dinoex.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jun 11, 2020 at 10:53:15PM +0200, Laurenz Albe wrote:
! On Thu, 2020-06-11 at 22:35 +0200, Magnus Hagander wrote:
! > I believe somebody around that time also wrote a set of bash scripts that can be used in a pre/post-backup-job combination with the current APIs.
!
! https://github.com/cybertec-postgresql/safe-backup
Ah, thank You, very nice.
I've never seen anybody coding bash - it is strongly shunned in the
Berkeley community.
Some Questions:
1. There are explicit error messages in loc-82 and -92 of pgpre.sh.
To where are these written?
2. The result data from pg_stop_backup() are stored into the living
database. But, according to the docs, they should be placed into
the completed backup. Do I have a misunderstanding here?
3. The most common error cause of a backup might be tape-side
malfunction. So far as I see, the way to handle this is currently,
to provide a timeout for pgpre.sh (which is problematic, because
we might as well have just reached end-of-tape and have to wait
until monday for the operator to change it). May I suggest to add
a switch to pgpost.sh, in order to volutarily fail out of the job?
4. If, by misconfiguration and/or operator error, the backup system
happens to start a second backup. in parallel to the first,
then do I correctly assume, both backups will be rendered
inconsistent while this may not be visible to the operator; and
the earlier backup would be flagged as apparently successful while
carrying the wrong (later) label?
BTW: what does, in general, happen, if a backup_label file gets
accidentially swapped with one from a parallel, but slightly later
backup? Do I correctly assume that such mistake gets somehow detected,
as otherwise it would have just the same unwelcome effects
(i.e. silent data corruption) as no backup_label at all?
cheerio,
PMc
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2020-06-13 04:39:58 | Returning SELECTed rows immediately instead of all at the end? |
Previous Message | sekhar chandra | 2020-06-12 22:56:51 | Fwd: not able to give usage access to public schema |