Re: Dividing progress/debug information in pg_standby, and stat before copy - Mailing list pgsql-hackers

Josh Berkus wrote:
> We discussed this issue at LCA where I encountered these bogus error
> messages when I was doing the demo of HS.  I consider Selena's patch to
> be a bug-fix for beta of 9.0, not a feature.  Currently the database
> reports a lot of false error messages when running in standby mode, and
> once we have 1000's more users using standby mode, we're going to see a
> lot of related confusion.
>   

Does anyone have a complete list of the false error messages and what 
context they show up in so that a proper test case could be constructed?

I extracted some pg_standby changes from Simon last week that have some 
overlap with Selena's patch (better logging, remove bogus link feature, 
throw less false error messages out).  I'm not quite ready to submit 
anything here just yet, I'm going to break that into more targeted 
patches, but I will be later this week.  I share the concern here that 
some of these issues are annoying enough to be considered bugs, and I 
need to fix them regardless of whether anybody else does.  I'd be happy 
to work with Selena as a review pair here, to knock out the worst of the 
problems on this program, now that the use-case for it should be more 
popular.  pg_standby could use a bit of an upgrade based on the rough 
edges found by all its field tests, most of which is in error handling 
and logging.  I don't have anything like her stat check in what I'm 
working on, so there's certainly useful stuff uniquely in each patch.

As far as her questions go:
> * Could we just re-use '-l' for logging?

The patch I'm working on adds "-v verbosity" so that logging can be a 
bit more fine-grained than that even.  Having both debug and a progress 
report boolean can then get folded into a single verbosity level, rather 
than maintain two similar paths.  Just make debug equal to the highest 
verbosity and maybe start deprecating that switch altogether.

One reason I'm not quite ready to submit what I've got yet is that I 
want to unify things better here.  I think that I'd prefer to use the 
same terminology as log_min_messages for the various options, and make a 
macro wrapper like ELOG this code uses instead of all these terrible 
direct fprintf([stderr|stdout]... calls.
> * Is there a way to get a non-module to use the ereport/elog system?

And that work would make this transition easier to make, too, if it 
became feasible.  I fear that's outside of the scope of what anyone 
wants to touch at this point though.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com