Re: Dividing progress/debug information in pg_standby, and stat before copy

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(at)2ndQuadrant(dot)com www.2ndQuadrant.com