From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | clarify documentation of BGW_NEVER_RESTART ? |
Date: | 2018-09-25 21:47:21 |
Message-ID: | 3d06d15d-f0f7-69b1-304b-c4de0b3a989c@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I did not notice until today that there is some ambiguity in
this paragraph:
bgw_restart_time is the interval, in seconds, that postgres should
wait before restarting the process, in case it crashes. It can be
any positive value, or BGW_NEVER_RESTART, indicating not to restart
the process in case of a crash.
I had been reading "in case _it_ crashes" and "in case of _a_ crash"
as "in case _the background worker_ crashes", so I assumed with
BGW_NEVER_RESTART I was saying I don't want my worker restarted if
_it_ flakes out while PG is otherwise operating normally.
But I was surprised when the unrelated crash of a different, normal
backend left my background worker killed and never restarted. I had
always regarded the fatal-error kick-out-all-backends-and-recover
handling as essentially equivalent to a PG restart, so I had expected
it to start the bgworker over just as a real restart would.
But sure enough, ResetBackgroundWorkerCrashTimes() gets called in
that case, and treats every worker with BGW_NEVER_RESTART as gone
and forgotten. So it seems the "it" in "it crashes" can be "the
background worker" or "postgres itself" or "any shmem-connected
backend".
If the wording fooled me it might fool somebody else too. I can
work on wordsmithing a patch to match the doc to the behavior,
but wanted first to check that the behavior is what was intended.
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-25 21:50:02 | Re: transction_timestamp() inside of procedures |
Previous Message | Andres Freund | 2018-09-25 20:17:23 | Re: Query is over 2x slower with jit=on |