Hi,
I have two questions about the stats collector during recovery.
1)
Why does the stats collector need to wait for consistent recovery
mode? The activity statistics which bgwriter may send before
reaching the mode should be ignored?
2)
Why doesn't ServerLoop() try to restart the stats collecto
Heikki Linnakangas wrote:
Tom Lane wrote:
Couldn't you get rid of PMSIGNAL_RECOVERY_COMPLETED altogether? If the
startup process exits with code 0, recovery is complete, else there
was trouble. I find this SetPostmasterSignal bit quite ugly anyway.
Right now, the startup process exits with c
Tom Lane wrote:
Couldn't you get rid of PMSIGNAL_RECOVERY_COMPLETED altogether? If the
startup process exits with code 0, recovery is complete, else there
was trouble. I find this SetPostmasterSignal bit quite ugly anyway.
Right now, the startup process exits with code 0 also when it's told t
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The thing wrong with it is assuming that nothing interesting will happen
>> during proc_exit(). We hang enough stuff on on_proc_exit hooks that
>> that seems like a pretty shaky assumption.
> I can't get too worried, given that proc_exit() is a ver
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Maybe the postmaster should wait for startup process exit before
deciding to open for business, instead of just a signal.
Not a bad idea. Although, there's nothing wrong with the current way
either. The startup process does a proc_e
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Maybe the postmaster should wait for startup process exit before
>> deciding to open for business, instead of just a signal.
> Not a bad idea. Although, there's nothing wrong with the current way
> either. The startup process does a proc_exit(0) ri
Tom Lane wrote:
Heikki Linnakangas writes:
Simon Riggs wrote:
More likely to be an uncommon race condition, rather than a error
specific to dungbeetle. If startup process death is slow, this could
happen, though hasn't occurred in other tests.
True, the startup process can live for a short
Heikki Linnakangas writes:
> Simon Riggs wrote:
>> More likely to be an uncommon race condition, rather than a error
>> specific to dungbeetle. If startup process death is slow, this could
>> happen, though hasn't occurred in other tests.
> True, the startup process can live for a short while co
Simon Riggs wrote:
More likely to be an uncommon race condition, rather than a error
specific to dungbeetle. If startup process death is slow, this could
happen, though hasn't occurred in other tests.
True, the startup process can live for a short while concurrently with
bgwriter, walwriter a
Simon Riggs writes:
>>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dungbeetle&dt=2009-02-18%2019:44:01
> More likely to be an uncommon race condition, rather than a error
> specific to dungbeetle.
I agree, that's what it looks like, especially since I couldn't
duplicate it on Fedora 9 x86
On Wed, 2009-02-18 at 21:28 +, Simon Riggs wrote:
> On Wed, 2009-02-18 at 15:43 -0500, Tom Lane wrote:
> > hei...@postgresql.org (Heikki Linnakangas) writes:
> > > Log Message:
> > > ---
> > > Start background writer during archive recovery.
> >
> > Might that have anything to do with
On Wed, 2009-02-18 at 15:43 -0500, Tom Lane wrote:
> hei...@postgresql.org (Heikki Linnakangas) writes:
> > Log Message:
> > ---
> > Start background writer during archive recovery.
>
> Might that have anything to do with this?
>
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dungbe
12 matches
Mail list logo
