Re: "stuck spinlock"

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: "stuck spinlock"
Дата
Msg-id 20131213181551.GR29402@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: "stuck spinlock"  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "stuck spinlock"
Список pgsql-hackers
On 2013-12-13 12:54:09 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > I wonder what to do about bgworker's bgworker_die()? I don't really see
> > how that can be fixed without breaking the API?
> 
> IMO it should be flushed and bgworkers should use the same die() handler
> as every other backend, or else one like the one in worker_spi, which just
> sets a flag for testing later.

Agreed on not going forward like now, but I don't really see how they
could usefully use die(). I think we should just mandate that every
bgworker conneced to shared memory registers a sigterm handler - we
could put a check into BackgroundWorkerUnblockSignals(). We should leave
the current handler in for unconnected one though...
bgworkers are supposed to be written as a loop around procLatch, so
adding a !got_sigterm, probably isn't too hard.

It sucks that people might have bgworkers out there that don't register
their own sigterm handlers, but adding a sigterm handler will be
backward compatible and it's in the example bgworker, so it's probably
not too bad.

> If we try to change the signal handling
> contracts, 80% of backend code will be unusable in bgworkers, which is not
> where we want to be I think.

Yea, I think that's out of the question.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "stuck spinlock"
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: patch: make_timestamp function