Re: Fatal Errors

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Fatal Errors
Дата
Msg-id 1222700390.4445.1269.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Fatal Errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fatal Errors
Список pgsql-hackers
On Mon, 2008-09-29 at 10:30 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Is it possible to have a FATAL error that crashes a backend and for it
> > to *not* have written an abort WAL record for any previously active
> > transaction? 
> 
> Well, a FATAL error will still go through transaction abort before
> exiting, IIRC.  The problem case is a PANIC or an actual core dump.

> > If we either *always* write a WAL record, or PANIC then that
> > makes some coding easier,
> 
> Like what?

For constructing snapshots during standby. I need a data structure where
emulated-as-running transactions can live. If backend birth/death is
intimately tied to WAL visible events then I can use dummy PGPROC
structures. If not, then I will have to create a special area that can
expand to cater for the possibility that a backend dies and WAL replay
won't know about it - which also means I would need to periodically dump
a list of running backends into WAL.

PANIC isn't a problem case because we'll end up generating a shutdown
checkpoint which shows the backends have been terminated.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fatal Errors
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Infrastructure changes for recovery