From: Michael Banck <michael.banck@credativ.de>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Sergei Kornilov <sk@zsrv.org>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Offline enabling/disabling of data checksums
Date: Tue, 19 Mar 2019 17:08:17 +0100
Message-ID: <1553011697.9697.55.camel@credativ.de> (raw)
In-Reply-To: <20190319160037.baalicue7ovkhvb2@alap3.anarazel.de>
References: <20190314043936.GH3493@paquier.xyz>
<CABUevExjCOKDRX=B6fBkoYs7Q2jYJLZS4Bxh1pi0b2_BV-7DEA@mail.gmail.com>
<1552577180.9697.4.camel@credativ.de>
<20190315025027.GN3493@paquier.xyz>
<1552650841.9697.22.camel@credativ.de>
<20190315122309.GA1434@paquier.xyz>
<1552653447.9697.24.camel@credativ.de>
<20190318081301.GH1885@paquier.xyz>
<20190319153626.vgxcem5r65yhydck@alap3.anarazel.de>
<1553010912.9697.53.camel@credativ.de>
<20190319160037.baalicue7ovkhvb2@alap3.anarazel.de>
Hi,
Am Dienstag, den 19.03.2019, 09:00 -0700 schrieb Andres Freund:
> On 2019-03-19 16:55:12 +0100, Michael Banck wrote:
> > Am Dienstag, den 19.03.2019, 08:36 -0700 schrieb Andres Freund:
> > > On 2019-03-18 17:13:01 +0900, Michael Paquier wrote:
> > > > +/*
> > > > + * Locations of persistent and temporary control files. The control
> > > > + * file gets renamed into a temporary location when enabling checksums
> > > > + * to prevent a parallel startup of Postgres.
> > > > + */
> > > > +#define CONTROL_FILE_PATH "global/pg_control"
> > > > +#define CONTROL_FILE_PATH_TEMP CONTROL_FILE_PATH ".pg_checksums_in_progress"
> > >
> > > I think this should be outright rejected. Again, you're making the
> > > control file into something it isn't. And there's no buyin for this as
> > > far as I can tell outside of Fabien and you. For crying out loud, if the
> > > server crashes during this YOU'VE CORRUPTED THE CLUSTER.
> >
> > The cluster is supposed to be offline during this. This is just an
> > additional precaution so that nobody starts it during the operation -
> > similar to how pg_upgrade disables the old data directory.
>
> I don't see how that matters. Afterwards the cluster needs low level
> surgery to be recovered. That's a) undocumented b) likely to be done
> wrongly. This is completely unacceptable *AND UNNECESSARY*.
Can you explain why low level surgery is needed and how that would look
like?
If pg_checksums successfully enables checksums, it will move back the
control file and update the checksum version - the cluster is ready to
be started again unless I am missing something?
If pg_checksums is interrupted by the admin, it will move back the
control file and the cluster is ready to be started again as well.
If pg_checksums aborts with a failure, the admin will have to move back
the control file before starting up the instance again, but I don't
think that counts?
If pg_checksums crashes due to I/O failures or other causes I can see
how possibly the block it was currently writing might need low level
surgery, but in that case we are in the domain of forensics already I
guess and that still does not pertain to the control file?
Sorry for being obtuse, I don't get it.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
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-hackers@postgresql.org
Cc: michael.banck@credativ.de, andres@anarazel.de, michael@paquier.xyz, magnus@hagander.net, coelho@cri.ensmp.fr, sk@zsrv.org, pgsql-hackers@lists.postgresql.org
Subject: Re: Offline enabling/disabling of data checksums
In-Reply-To: <1553011697.9697.55.camel@credativ.de>
* 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