On Mon, Jul 27, 2015 at 07:59:40AM +0100, Simon Riggs wrote: > On 26 July 2015 at 20:15, Noah Misch <n...@leadboat.com> wrote: > > On Fri, Jul 24, 2015 at 09:14:09PM -0400, Peter Eisentraut wrote: > > > On 7/22/15 4:45 PM, Robert Haas wrote: > > > > But it seemed to me that this could be rather confusing. I thought it > > > > would be better to be explicit about whether the protections are > > > > enabled in all cases. That way, (1) if you see the message saying > > > > they are enabled, they are enabled; (2) if you see the message saying > > > > they are disabled, they are disabled; and (3) if you see neither > > > > message, your version does not have those protections. > > > > > > But this is not documented, AFAICT, so I don't think anyone is going to > > > be able to follow that logic. I don't see anything in the release notes > > > saying, look for this message to see how this applies to you, or > > whatever. > > > > I supported inclusion of the message, because it has good potential to help > > experts studying historical logs to find the root cause of data corruption. > > The complex histories of clusters showing corruption from this series of > > bugs > > have brought great expense to the task of debugging new reports. Given a > > cluster having full mxact wraparound protections since last corruption-free > > backup (or since initdb), one can rule out some causes. > > > Would it be better to replace it with a less specific and more generally > useful message? > > For example, Server started with release X.y.z > from which we could infer various useful things.
That message does sound generally useful, but we couldn't infer $subject from it. While the $subject message appears at startup in simple cases, autovacuum prerequisite work can delay it indefinitely. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
