Re: Fatal Errors
От | Simon Riggs |
---|---|
Тема | Re: Fatal Errors |
Дата | |
Msg-id | 1222702374.4445.1279.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Fatal Errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fatal Errors
|
Список | pgsql-hackers |
On Mon, 2008-09-29 at 11:18 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Mon, 2008-09-29 at 10:30 -0400, Tom Lane wrote: > >> 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. > > Mph. I find the idea of assuming that there must be an abort record to > be unacceptably fragile. Consider the possibility that the transaction > gets an error while trying to run AbortTransaction. Some of that code > is a CRITICAL_SECTION, but I don't think I like the idea that all of it > has to be one. Aware of possibility fragility, hence the post. Few thoughts: * Is it close enough that we can get away with having a few spare slots to cater for that possibility? * Might we make AbortTransaction critical just as far as the END_CRIT_SECTION after XLogInsert in RecordTransactionAbort(), but no further? Don't expect yes, but seems worth recording thoughts. > > PANIC isn't a problem case because we'll end up generating a shutdown > > checkpoint which shows the backends have been terminated. > > Thought you were trying to get rid of the shutdown checkpoint during > restart? Yes, but if I do there would still be a WAL record of some kind there to allow us to confirm the change of tli. Anyway, I thought you wanted me to keep it now? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: