Re: Parallel worker hangs while handling errors.
От | Robert Haas |
---|---|
Тема | Re: Parallel worker hangs while handling errors. |
Дата | |
Msg-id | CA+TgmoYZFx_wGEk_h426YBdGf81DCGuNd4ikSE6v60JaCbswuw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel worker hangs while handling errors. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Parallel worker hangs while handling errors.
|
Список | pgsql-hackers |
On Fri, Sep 11, 2020 at 4:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > It's not clear to me whether we want to institute the "accepting SIGQUIT > is always okay" rule in processes that didn't already have code to change > BlockSig. The relevant processes are pgarch.c, startup.c, bgworker.c, > autovacuum.c (launcher and workers both), and walsender.c. In the first > two of these I doubt it matters, because I don't think they'll ever block > signals again anyway -- they certainly don't have outer sigsetjmp blocks. > And I'm a bit hesitant to mess with bgworker given that we seem to expect > that to be heavily used by extension code, and we're exposing code to > allow extensions to mess with the signal blocking state. On the other > hand, as long as SIGQUIT is pointing at SignalHandlerForCrashExit, it's > hard to see a reason why holding it off could be necessary. So maybe > having a uniform rule would be good. > > Any thoughts about that? I think a backend process that isn't timely handling SIGQUIT is by that very fact buggy. "pg_ctl stop -mi" isn't a friendly suggestion. So I favor trying to make it uniform. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: