From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Thorsten Schöning <tschoening@am-soft.de>
To: pgsql-admin@lists.postgresql.org
Subject: Re: What's the dfifference between pg_start_backup+copy+pg_stop_backup+WAL vs. pg_start_backup+pg_stop_backup+copy+WAL?
Date: Fri, 23 Jul 2021 18:26:18 +0200
Message-ID: <32a24a871174e9362225be407a234251e837d9aa.camel@cybertec.at> (raw)
In-Reply-To: <1751752722.20210723161202@am-soft.de>
References: <1208702063.20210723115638@am-soft.de>
<399c734c5b9ffe10f68bcb79a69bea000d8d0c21.camel@cybertec.at>
<1751752722.20210723161202@am-soft.de>
On Fri, 2021-07-23 at 16:12 +0200, Thorsten Schöning wrote:
> I think your example is bad: If both rows are added in independent
> transactions, possibly inconsistent table data simply needs to be
> accepted. No backup mechanism will change anything on that, because
> the second row might always be inserted "too late".
Stephen has already pointed out the flaws in your reasoning, so let
me illustrate my example in more detail:
You add the rows in A and B in two different transactions: first
the row in A, then the dependent row in B.
At that time the data file for A has already been backed up.
After both rows are committed, the data file for B is backed up.
Now if you replay WAL to a point in time before all that took
place (which you can do, because your BACKUP_END record was written
before you started your backup), you will have the row in B, but
not the row in A. Data corruption.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: laurenz.albe@cybertec.at, tschoening@am-soft.de, pgsql-admin@lists.postgresql.org
Subject: Re: What's the dfifference between pg_start_backup+copy+pg_stop_backup+WAL vs. pg_start_backup+pg_stop_backup+copy+WAL?
In-Reply-To: <32a24a871174e9362225be407a234251e837d9aa.camel@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox