From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Sergei Kornilov <sk(at)zsrv(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Online enabling of checksums |
Date: | 2018-09-29 12:19:59 |
Message-ID: | 20180929121959.GN4184@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Tomas Vondra (tomas(dot)vondra(at)2ndquadrant(dot)com) wrote:
> While looking at the online checksum verification patch (which I guess
> will get committed before this one), it occurred to me that disabling
> checksums may need to be more elaborate, to protect against someone
> using the stale flag value (instead of simply switching to "off"
> assuming that's fine).
>
> The signals etc. seem good enough for our internal stuff, but what if
> someone uses the flag in a different way? E.g. the online checksum
> verification runs as an independent process (i.e. not a backend) and
> reads the control file to find out if the checksums are enabled or not.
> So if we just switch from "on" to "off" that will break.
>
> Of course, we may also say "Don't disable checksums while online
> verification is running!" but that's not ideal.
I'm not really sure what else we could say here..? I don't particularly
see an issue with telling people that if they disable checksums while
they're running a tool that's checking the checksums that they're going
to get odd results.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | David Hedberg | 2018-09-29 12:51:33 | Adding pipe support to pg_dump and pg_restore |
Previous Message | Stephen Frost | 2018-09-29 12:14:02 | Re: Online verification of checksums |