On 2/20/17 11:22 AM, David Christensen wrote:
>> - If an entire cluster is going to be considered as checksummed, then even databases that don't allow connections
wouldneed to get enabled.
> Yeah, the workaround for now would be to require “datallowconn" to be set to ’t' for all databases before proceeding,
unlessthere’s a way to connect to those databases internally that bypasses that check. Open to ideas, though for a
firstpass seems like the “datallowconn” approach is the least amount of work.
The problem with ignoring datallowconn is any database where that's
false is fair game for CREATE DATABASE. I think just enforcing that
everything's connectable is good enough for now.
>> I like the idea of revalidation, but I'd suggest leaving that off of the first pass.
> Yeah, agreed.
>
>> It might be easier on a first pass to look at supporting per-database checksums (in this case, essentially treating
sharedcatalogs as their own database). All normal backends do per-database stuff (such as setting current_database)
duringstartup anyway. That doesn't really help for things like recovery and replication though. :/ And there's still
thequestion of SLRUs (or are those not checksum'd today??).
> So you’re suggesting that the data_checksums GUC get set per-database context, so once it’s fully enabled in the
specificdatabase it treats it as in enforcing state, even if the rest of the cluster hasn’t completed? Hmm, might
thinkon that a bit, but it seems pretty straightforward.
Something like that, yeah.
> What issues do you see affecting replication and recovery specifically (other than the entire cluster not being
complete)? Since the checksum changes are WAL logged, seems you be no worse the wear on a standby if you had to change
things.
I'm specifically worried about the entire cluster not being complete.
That makes it harder for replicas to know what blocks they can and can't
verify the checksum on.
That *might* still be simpler than trying to handle converting the
entire cluster in one shot. If it's not simpler I certainly wouldn't do
it right now.
>> BTW, it occurs to me that this is related to the problem we have with trying to make changes that break page binary
compatibility.If we had a method for handling that it would probably be useful for enabling checksums as well. You'd
essentiallytreat an un-checksum'd page as if it was an "old page version". The biggest problem there is dealing with
thepotential that the new page needs to be larger than the old one was, but maybe there's some useful progress to be
hadin this area before tackling the "page too small" problem.
> I agree it’s very similar; my issue is I don’t want to have to postpone handling a specific case for some future
infrastructure.
Yeah, I was just mentioning it.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)