Re: Offline enabling/disabling of data checksums - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Offline enabling/disabling of data checksums
Date
Msg-id alpine.DEB.2.21.1903200742030.24709@lancre
Whole thread Raw
In response to Re: Offline enabling/disabling of data checksums  (Andres Freund <andres@anarazel.de>)
Responses Re: Offline enabling/disabling of data checksums
List pgsql-hackers
Hallo Andres,

> And you're basically adding it because Fabien doesn't like
> postmaster.pid and wants to invent another lockout mechanism in this
> thread.

I did not suggest to rename the control file, but as it is already done by 
another command it did not look like a bad idea in itself, or at least an 
already used bad idea:-)

I'd be okay with anything that works consistently accross all commands 
that may touch a cluster and are mutually exclusive (postmater, pg_rewind, 
pg_resetwal, pg_upgrade, pg_checksums…), without underlying race 
conditions. It could be locking, a control file state, a special file 
(which one ? what is the procedure to create/remove it safely and avoid 
potential race conditions ?), possibly "postmaster.pid", whatever really.

I'll admit that I'm moderately enthousiastic about "posmaster.pid" because 
it does not do anymore what the file names says, but if it really works 
and is used consistently by all commands, why not. In case of unexpected 
problems, the file will probably have to be removed/fixed by hand. I also 
think that the implemented mechanism should be made available in 
"control_utils.c", not duplicated in every command.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: "Iwata, Aya"
Date:
Subject: RE: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead
Next
From: Andres Freund
Date:
Subject: Re: Offline enabling/disabling of data checksums