On 08/01/2018 09:20 AM, Alvaro Herrera wrote:
my problem is that I think the "restart" approach is just using the
entirely wrong hammer to solve the problem at hand. At the very least
it's very problematic in respect to replicas, which need to know about
the setting too, and can have similar problems the restart on the
primary is supposed to prevent.
If we define "restart" to mean taking all the servers down
simultaneously, that can be planned.
People in mission critical environments do not "restart all servers".
They fail over to a secondary to do maintenance on a primary. When you
have a system where you literally lose thousands of dollars every minute
the database is down you can't do what you are proposing. When you have
a system that if the database is down for longer than X minutes, you
actually lose a whole day because all of the fabricators have to
revalidate before they begin work, you can't do that. Granted that is
not the majority (which you mention) but let's not forget them.
The one place where a restart does happen and will continue to happen
for around 5 (3 if you incorporate pg_logical and 9.6) more years is
upgrades. Although we have logical replication for upgrades now, we are
5 years away from the majority of users being on a version of PostgreSQL
that supports logical replication for upgrades. So, I can see an
argument for an incremental approach because people could enable
checksums as part of their upgrade restart.
For users that cannot do that,
that's too bad, they'll have to wait to the next release in order to
enable checksums (assuming they fund the necessary development). But
I have to say, as a proponent of funded development for longer than most
I like to see this refreshing take on the fact that this all does take
money.
there are many systems where it *is* possible to take everything down
for five seconds, then back up. They can definitely take advantage of
checksummed data.
This is a good point.
Currently, the only way to enable checksums is to initdb and create a
new copy of the data from a logical backup, which could take hours or
even days if data is large, or use logical replication.
Originally, I was going to -1 how this is being implemented. I too wish
we had the "ALTER DATABASE ENABLE CHECKSUM" or equivalent without a
restart. However, being able to just restart is a huge step forward from
what we have now.
Lastly, I think Alvaro has a point with the incremental development and
I also think some others on this thread need to, "show me the patch"
instead of being armchair directors of development.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
*** A fault and talent of mine is to tell it exactly how it is. ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
***** Unless otherwise stated, opinions are my own. *****
