Re: Hard limit on WAL space used (because PANIC sucks)
От | Andres Freund |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | 20140122005812.GG32729@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hard limit on WAL space used (because PANIC sucks)
|
Список | pgsql-hackers |
On 2014-01-21 19:45:19 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-01-21 19:23:57 -0500, Tom Lane wrote: > >> I'm not suggesting that we stop providing that information! I'm just > >> saying that we perhaps don't need to store it all in one WAL record, > >> if instead we put the onus on WAL replay to be able to reconstruct what > >> it needs from a series of WAL records. > > > That'd likely require something similar to the incomplete actions used > > in btrees (and until recently in more places). I think that is/was a > > disaster I really don't want to extend. > > I don't think that's a comparable case. Incomplete actions are actions > to be taken immediately, and which the replayer then has to complete > somehow if it doesn't find the rest of the action in the WAL sequence. > The only thing to be done with the records I'm proposing is to remember > their contents (in some fashion) until it's time to apply them. If you > hit end of WAL you don't really have to do anything. Would that work for the promotion case as well? Afair there's the assumption that everything >= TransactionXmin can be looked up in pg_subtrans or in the procarray - which afaics wouldn't be the case with your scheme? And TransactionXmin could very well be below such an "incomplete commit"'s xids afaics. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: