From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer code behaving strangely on postmaster -T |
Date: | 2012-05-10 15:14:01 |
Message-ID: | 994.1336662841@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of jue may 10 02:27:32 -0400 2012:
>> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I noticed while doing some tests that the checkpointer process does not
> recover very nicely after a backend crashes under postmaster -T
> It seems to me that the bug is in the postmaster state machine rather
> than checkpointer itself. After a few false starts, this seems to fix
> it:
> --- a/src/backend/postmaster/postmaster.c
> +++ b/src/backend/postmaster/postmaster.c
> @@ -2136,6 +2136,8 @@ pmdie(SIGNAL_ARGS)
> signal_child(WalWriterPID, SIGTERM);
> if (BgWriterPID != 0)
> signal_child(BgWriterPID, SIGTERM);
> + if (FatalError && CheckpointerPID != 0)
> + signal_child(CheckpointerPID, SIGUSR2);
Surely we do not want the checkpointer doing a shutdown checkpoint here.
If we need it to die immediately, SIGQUIT is the way. If we want a
shutdown checkpoint, that has to wait till after everything else is
known dead. So while I agree this may be a state machine bug, that
doesn't look like a good fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-05-10 15:16:02 | Re: Draft release notes complete |
Previous Message | MauMau | 2012-05-10 15:07:59 | Re: Can pg_trgm handle non-alphanumeric characters? |