Re: clog_redo causing very long recovery time
От | Joe Conway |
---|---|
Тема | Re: clog_redo causing very long recovery time |
Дата | |
Msg-id | 4DC36DD6.8030405@joeconway.com обсуждение исходный текст |
Ответ на | Re: clog_redo causing very long recovery time (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: clog_redo causing very long recovery time
|
Список | pgsql-hackers |
On 05/05/2011 08:22 PM, Tom Lane wrote: > Joseph Conway <mail@joeconway.com> writes: >> The attached fix-clogredo diff is my proposal for a fix for this. > > That seems pretty grotty :-( > > I think a more elegant fix might be to just swap the order of the > ExtendCLOG and ExtendSUBTRANS calls in GetNewTransactionId. The > reason that would help is that pg_subtrans isn't WAL-logged, so if > we succeed doing ExtendSUBTRANS and then fail in ExtendCLOG, we > won't have written any XLOG entry, and thus repeated failures will not > result in repeated XLOG entries. I seem to recall having considered > exactly that point when the clog WAL support was first done, but the > scenario evidently wasn't considered when subtransactions were stuck > in :-(. Yes, that does seem much nicer :-) > It would probably also help to put in a comment admonishing people > to not add stuff right there. I see the SSI guys have fallen into > the same trap. Right -- I think another similar problem exists in GetNewMultiXactId where ExtendMultiXactOffset could succeed and write an XLOG entry and then ExtendMultiXactMember could fail before advancing nextMXact. The problem in this case is that they both write XLOG entries, so a simple reversal doesn't help. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support
В списке pgsql-hackers по дате отправления: