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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Harold Giménez
Дата:
Сообщение: Re: proposal: hide application_name from other users
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: proposal: hide application_name from other users