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 по дате отправления: