Skip site navigation (1) Skip section navigation (2)

Re: Upgrading postmaster's log messages about bind/listen errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Euler Taveira <euler(at)timbira(dot)com(dot)br>, Robert Haas <robertmhaas(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Upgrading postmaster's log messages about bind/listen errors
Date: 2017-03-10 23:40:14
Message-ID: 17211.1489189214@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
I wrote:
> I think that what would actually be of some use nowadays is a LOG-level
> message emitted if the wraparound *isn't* activated immediately at start.
> But otherwise, we should follow the rule that silence is golden.

Concretely, how about the attached?  It preserves the original
"protections are now enabled" message at LOG level, but emits it only
when oldestOffsetKnown becomes true *after* startup.  Meanwhile, if
oldestOffsetKnown is still not true at the conclusion of TrimMultiXact,
then it emits a new LOG message about "protections are not active".
In this way we have LOG messages but they're only emitted in "interesting"
cases.

I dropped the IsUnderPostmaster test because I see no good reason not
to warn in standalone backends as well.

I think this might actually be a reasonable candidate to back-patch,
because a deficiency of the existing code is that it fails to warn
you when something's wrong.  But in any case I'd like to put it in HEAD.

			regards, tom lane


Attachment: better-multixact-wraparound-messaging.patch
Description: text/x-diff (9.0 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2017-03-10 23:57:00
Subject: Re: Need a builtin way to run all tests faster manner
Previous:From: Corey HuinkerDate: 2017-03-10 23:19:25
Subject: Re: asynchronous execution

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group